[openstack-dev] [Solum] Version scheme

Noorul Islam K M noorul at noorul.com
Thu Nov 14 16:26:58 UTC 2013


Monty Taylor <mordred at inaugust.com> writes:

> 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.
>

Thank you for explaining in detail. This is insightful!

Regards,
Noorul

>> 
>> 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
>> 
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list