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 >> [email protected] >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion > _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
