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