cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: In-Development Release Naming
Date Mon, 01 Jul 2013 20:42:39 GMT
On Mon, Jul 01, 2013 at 10:40:38PM +0200, Daan Hoogland wrote:
> That doesn't invalidate John's point about the message to the users. We can
> publish it by a code name and still code it with numbers according to our
> expectations of the level of bump it will take.

Ah...  I guess I was thinking that this was an all-inclusive proposal.

Sounds fine to me.  I'd suggest that 4.2 is out of the bag now, but how
about for our next feature release?

> 
> 
> On Mon, Jul 1, 2013 at 10:15 PM, Chip Childers <chipchilders@apache.org>wrote:
> 
> > On Mon, Jul 01, 2013 at 02:28:37PM -0400, John Burwell wrote:
> > > All,
> > >
> > > Since we have adopted Semantic Versioning [1], it seems odd that we
> > designate a release version before the final set of enhancements/fixes has
> > been identified.  For example, the release proceeding 4.2 may contain no
> > backwards compatible API changes to be 4.3.  Conversely, we may decide
> > during the development cycle, as a community, to accept a non-backwards
> > compatible change which would bump the version to 5.0.0.  As such, it is
> > difficult to know in advance what the proper semantic version number will
> > be at when the work is released.  We run the risk of confusing our users if
> > we start calling a pending release say 4.3.0, and accept a change mid-cycle
> > that will bump it to 5.0.0.  To address this potential issue, I proposed
> > that we refer to releases by a codename until feature freeze when we
> > understand the complete scope of change and can apply the correct semantic
> > version number.  I further propose we codename the release directly
> > proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".
> > >
> > > Thoughts?
> > > -John
> > >
> > > [1]: http://semver.org
> >
> > Some technical issues to address WRT versions prior to a number being
> > assigned:
> >
> > 1) package version strings (DEB and RPM)
> > 2) DB version string, especially for testing upgrades
> >
> > Thoughts on how to avoid issues here?
> >
> > To me, it seems like we should make an upgrade to 5.x a *major discussion*,
> > and instead *assume* that we will retain backward compatibility and not
> > bump
> > the major number.  I'd rather limit the number of times that we
> > actually jump major versions and take the hit on the version numbering
> > changes when those times to occur.  Just my 2 cents though.
> >
> > -chip
> >

Mime
View raw message