First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs
  • Date: Wed, 09 Jan 2008 15:44:48 +1300
James Lawson wrote:
> Andrew Miller wrote:
>> Hi all,
>>
> Hi, thanks for providing a nice intro to this issue Andrew.
>> There have recently been some discussions of changes which would
>> drastically break forwards or backwards compatibility of CellML (for
>> example, changing the way that connections work).
>>
>> I think that it is important that we come to some consensus on what
>> the policy for inter-version compatibility in CellML should be quite
>> soon, because this drastically affects decisions that need to be made
>> in CellML specification development.
>>
>> It doesn't really make sense to be inconsistent with respect to
>> version compatibility - it would be quite unfortunate if we worked
>> hard to keep compatibility for one part of CellML, and then broke it
>> in another major part such as by changing the way connections work,
>> and so I think we need a policy on this.
>>
> I certainly agree with you that we need to keep policy consistent.
> However the possibility that immediately came to mind is that we could
> group versions of the specification with respect to interversion
> compatibility. If we have major decisions to make regarding the
> continuing integrity of the language that might break compatibility, I
> think we must reserve the right to do this, giving careful
> consideration of the impact to the community of course. For example,
> if we were to break compatibility of 1.0 and 1.1 with 1.2, but have
> 1.3 and 1.4 compatible with 1.2, this would reduce development
> workload compared with a policy of not requiring version compatibility
> between successive versions at all. Perhaps this is an approach we
> might want to take between, say CellML 1.X and CellML 2.X - that is,
> we reserve major changes that will break compatibility for major
> versioning events.

One thing which I didn't state as clearly as I probably should have is
that I am proposing that we decide on a policy for how we deal with the
next version of CellML. By policy, I mean a uniting concept which
applies to all issues in the development of the next version of the
specification, as opposed to something which would apply across
specification versions. I am not suggesting that we need to set a policy
in stone for all future versions - it is likely that decisions like this
will be reviewed by the community when we are working on post-1.2
versions of CellML if there need to do so.

Best regards,
Andrew

>> I have come up with a number of different potential policy statements
>> on when backwards compatibility should be broken and when it should
>> be kept. It might help us to reach consensus if members of the CellML
>> community could rank the policies in order of preference (1 is the
>> most preferable policy, 2 the next most, and so on), and suggest any
>> good policies that may be missing.
>>
>> Option A)
>> Future versions of CellML should aim to solely express the intention
>> of previous versions better and more clearly. They should aim to keep
>> full compatibility with an implementation of the specification
>> according to the rules of the specification as they were interpreted
>> by implementors.
>>
>> Option B)
>> Future versions of CellML should try to be mostly compatible with
>> existing implementations of previous versions of CellML. They may
>> remove functionality that does not have an established base of
>> software which correctly implements that functionality. They may also
>> add in new functionality, if that new functionality significantly
>> increases the expressiveness of the language. However, in normal
>> circumstances, compatibility should be maintained, so that when a
>> model not using new features is saved in the new version's most
>> preferred format, it can still be correctly loaded into software only
>> supporting the old version. Likewise, a model not using any removed
>> features should be able to be loaded in software supporting only the
>> new version of the specification.
>>
>> Option C)
>> Future versions of CellML should make any changes which make it
>> conceptually cleaner, even if there is a less clean compromise
>> available that would have lesser compatibility implications. Software
>> will need to explicitly support more than one version as a completely
>> separate format.
>>
>> My preferred choice is Option B. Despite being apparently at opposite
>> ends of the spectrum, Option A and Option C are, in my opinion,
>> fairly similar, because if we adopted Option A, larger changes would
>> appear in a new specification called something other than CellML.
>> Although there could be advantages of coming up with a more
>> meaningful name than CellML, I think that this would also set us back
>> in terms of community awareness of the specification, and so I think
>> that Option C is marginally better than Option A (i.e. my personal
>> order of preference is currently B:1, C:2, A:3).
>>
> I would have to concur - out of those three possibilities, B would be
> preferable.
>
> Kind regards,
> James
>> I look forward to any feedback on this you may have.
>>
>> Best regards,
>> Andrew
>>
>> _______________________________________________
>> cellml-discussion mailing list
>> cellml-discussion at cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>



Archive powered by MHonArc 2.6.18.

Top of page