Hi Graeme, The release numbers are pretty well defined according to industry standard.
Specifically, in MCF's case, this is the arrangement: <major>.<minor>.<point> - Major release increments only when backwards compatibility is broken - Minor release increments for significant tri-monthly periodic updates - Point release means a patch or bug-fix release We're not allowed to do schema changes in point releases, for instance, but minor releases we can. But it is also allowed to put straightforward feature improvements out in point releases; we just haven't had the need. There are also no plans at the time to bump the major release number; the kind of thing that would require such a bump might be reimplementing ManifoldCF on top of Voldemort, for instance. Karl On Fri, Mar 14, 2014 at 2:32 PM, Graeme Seaton <[email protected]> wrote: > To quickly follow up - we could also only increment the 'minor' version ie > 1.x every 6 months which would allow an amount of time for deployment > planning - the last thing I think any of us want is for versions in the > field to fall behind significantly due to 'upgrade' fatigue. > > Graeme > > > On 14/03/14 18:26, Graeme Seaton wrote: > >> Thanks to everyone for the greetings. >> >> IMHO, I'd still like to see 3 monthly releases (because it provides the >> project with a level of momentum) but perhaps we could structure them in a >> similar way to Intel's Tick/Tock approach - every other release is focussed >> on architectural/infrastructure related items (and potentially new >> connector functionality) while the other is a >> stabilisation/connectors-focussed >> release. >> >> (and yes I would love you to have the time to update the book :-D) >> >> Regards, >> >> Graeme >> >> On 14/03/14 11:53, Karl Wright wrote: >> >>> Also, FWIW, I would like to propose that we consider slowing down the >>> release cycle, maybe going from 3 months to 4 or 6 months per release. >>> While we've still been getting strong bursts of activity, we've also been >>> seeing relative lulls now, and the project is definitely getting more >>> mature. This might allow me time to update the book. ;-) >>> >>> Of course, this is a tradeoff. Getting new features out is important >>> both >>> for the development of the features and for the utility of the project to >>> others. Other projects release software based on some notion of how many >>> features/changes they've put into it. We too could do that -- but I've >>> found in my professional life that such a way of releasing software often >>> either leads to chronic release stress or releases that are so long >>> people >>> even forget what's in them. >>> >>> Thoughts welcome on how we should manage release cycles going forward. >>> >>> Karl >>> >>> >>> >>> On Wed, Mar 12, 2014 at 8:56 PM, Karl Wright <[email protected]> wrote: >>> >>> Hi folks, >>>> >>>> MCF 1.6 is scheduled to be released on April 30, and should be completed >>>> on April 15th, if we stick to the standard three-month release cycle for >>>> this project. >>>> >>>> There are a number of tickets I'd love to get resolved in this >>>> timeframe. >>>> I've listed the key ones below: >>>> >>>> CONNECTORS-909: Upgrade to the latest ElasticSearch (Abe Shinichiro) >>>> CONNECTORS-856: Get a mock testing framework working (Alessandro >>>> Benedetti, largely) >>>> CONNECTORS-565: SharePoint 2013 support (Karl Wright) >>>> >>>> Please let me know if there will be any problem finishing these tickets >>>> in >>>> a month. >>>> >>>> Thanks! >>>> >>>> Karl >>>> >>>> >>>> >> >
