Open Stack

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.

> 
> On Nov 14, 2013, at 8:23 AM, Noorul Islam K M <noorul at noorul.com
> <mailto:noorul at noorul.com>>
>  wrote:
> 
>>
>> Hello all,
>>
>> We need to decide on version scheme that we are going to use.
>>
>> Monty Taylor said the following in one of the comments for review [1]:
>>
>> Setting a version here enrolls solum in managing its version in a
>> pre-release versioning manner, such that non-tagged versions will
>> indicated that they are leading up to 0.0.1. If that's the model solum
>> wants to do (similar to the server projects) then I recommend replacing
>> 0.0.1 with 2014.1.0.
>>
>> Regards,
>> Noorul
>>
>> [1] https://review.openstack.org/#/c/56130/
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>