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