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