Or an alternative is to do a 3 monthly releases where even minor
releases involve architectural changes and odd's only include bug
fixes/new connectors.
Graeme
On 14/03/14 21:18, Graeme Seaton wrote:
Karl,
Thinking about it some more, guess I'm arguing for a 6 month minor
release number update with a defined 3 monthly point release in
between (with potential other minor releases intervening).
Regards,
Graeme
On 14/03/14 21:11, Graeme Seaton wrote:
Hi Karl,
Don't disagree but was thinking that Tick releases would be labelled
1.6.0 (for example) and the Tock would be 1.6.5 to conform with the
conventions. If we ran into significant issues then interim releases
would be (for example) 1.6.1 and 1.6.6 (and if we need more space in
the numbering scheme then we probably have some major other issues).
Regards,
Graeme
On 14/03/14 18:41, Karl Wright wrote:
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
