On Wed, Mar 25, 2015 at 01:51:11PM +0000, Sam Thursfield wrote:
On 21/03/15 21:21, Richard Ipsum wrote:
>1) version 0 == unversioned, older definitions with no version file will
>be interpreted as version 0, any changes to morph will maintain backwards
>compatibility with version 0 for the time being.
>2) Branch morph and introduce version numbers to morph,
>there will be two active branches of morph, a 0.x.y branch
>and a 1.x.y branch, we may obviously decide on a different versioning
>scheme but regardless of versioning scheme there are two branches.
Both of these are sensible approaches, but I don't think either of
them are the right thing to do for Morph.
For option (2) especially, I think that the 0.x branch of Morph
would quickly become a 2nd-class citizen, and users who had decided
to stick with 'version 0' of definitions would find they were
missing out on lots of features and bugfixes. Generally, backporting
new features on top of old code is hard and unrewarding: unless
someone committed to a small amount of ongoing funding for
maintaining the 0.x branch, I'm not convinced it would be viable.
Sorry for the delay in replying, I think this is a good point and agree
My preferred approach is to get everyone to keep their definitions
up to date with changes to the format, and for us to provide
migration scripts in the repo so that this is easy for them to do.
Okay let's go with that then,
the main thing is to get this bug fixed,
so I'll leave the versioning as it is for now (unversioned == version 0)
and drop the suggestion that we branch morph.