Open Stack

----- Original Message -----
> 
> 
> On 11/14/2013 10:36 AM, Murali Allada wrote:
> > I'm not a big fan of using date information in the version number. Is
> > there an advantage to doing that? Using a model like 0.0.1 makes it
> > easier to communicate.
> > 
> > A better approach might be to use  *Major.Minor.Revision.Build*. If we
> > want to use dates, *Year.Month.Day.Build  or
> > Year.**Minor.Revision.Build *might be a better approach.. Do any
> > openstack projects use the build number in the version? or is there a
> > way for the build process to insert the build number in there?
> 
> To be clear, this isn't really a call to design a versioning scheme from
> scratch - there are two schemes currently in use, and solum should use
> one of them.
> 
> The main reason to do 2014.1.0 is to align with OpenStack, so it depends
> on intent a little bit. The advantage to the Year.Minor.Revision is
> that, since OpenStack is on a date-based release cycle, it communicates
> that fact.
> 
> The main reason to do a semver style Major.Minor.Patch scheme is to
> communicate api changes across releases. This is the reason we release
> our libraries using that scheme.
> 
> In terms of mechanics, the way it works for both schemes is that the
> version produced is based on git tags. If a revision is tagged, that is
> the version that is produced in the tarball.
> 
> If a version is NOT tagged, there are two approaches.
> 
> Since the date-based versions have a predictable next version, we have
> intermediary versions marked as leading up to that version.
> Specifically, the form is:
> 
> %(version_in_setup_cfg)s.dev%(num_revisions_since_last_tag)s.g%(git_short_sha)
> 
> the dev prefix is a PEP440 compliant indiciation that this is a
> development version that is leading towards the version indicated.
> 
> For semver-based versions, intermediary versions are marked as following
> the previous release. So we get:
> 
> %(most_recent_tag)s.%(num_revisions_since_last_tag)s.g%(git_short_sha)s
> 
> I would honestly recommend aligning with OpenStack and putting 2014.1.0
> into the setup.cfg version line for solum itself and doing date-based
> releases. For python-solumclient, since it's a library, I recommend not
> listing a version in setup.cfg and doing semver-based versions. This way
> you'll be operating in the same way as the rest of the project.
> 

+1, semver on unreleased versions conveys less useful information than date related info.