sfepy/sfepy — Issue #68: release numbering
Author: rc
Created: 2012-01-30 10:25:20+00:00
State: open

The current version numbering xx.yy.zz is based on the way I managed daily
tarball backups before I had started using a distributed source control
system (mercurial). Essentially, every daily backup increased the number
(zz for small changes, yy for bigger changes or finished sub-problem). I do
not create those daily tarballs anymore, so we need another scheme.

Proposals:

1. count the amount of changes since the last release, increase the version
number proportionally to it (but what constant of porportionality to use?)

for example:
$hg di -r 662 -Xwork/* | grep + | wc -l
14502

2. use date-based versions

3. ?

I would like this to have settled already for the next release (to be soon).

Migrated from http://code.google.com/p/sfepy/issues/detail?id=64

earlier comments

lukes@kme.zcu.cz said, at 2008-12-02T10:50:13.000Z:

My proposal:

"year"."number of release",

like Gentoo does it.

robert.cimrman said, at 2008-12-02T10:59:21.000Z:

I quite like it (it is in fact item 2. in the proposal list above).

So the next release would be sfepy-2008.4 (or sfepy_2008.4?) - "4" means the fourth
release in 2008.

ondrej.certik said, at 2008-12-02T11:15:50.000Z:

I suggest simply x.y.z and increase z by 1 with each release. Since the current
version is 00.50.00, I suggest starting with 0.6.0, and then 0.6.1, 0.6.2, ..., and
if you do something major, go to 0.7.0, etc. That way it is compatible with the
current scheme and also it will be compatible packaging scripts in Debian (and I am
sure in Gentoo as well), that remind you that there is a new upstream version
available. I am not sure they can parse date based versions.

ondrej.certik said, at 2008-12-02T11:18:23.000Z:

Besides, +1, I told you right from the beginning to use some sane versioning scheme
and you replied, nono, I really like this. :)

After this is fixed, I think I have no more stylistic comments. Yeah, actually, "f( 1
)" is very ugly too. I'll wait couple more months, but I am sure you'll fix it too. :)

robert.cimrman said, at 2008-12-02T11:36:53.000Z:

What is the problem with the Debian packaging scripts as long as the version number
is increasing, i.e. the "next version string" > "previous version string"?

I liked the old scheme at times I wrote sfepy alone, now I hope some other people
will help me, so I am ok with changing it :)

robert.cimrman said, at 2008-12-02T12:09:23.000Z:

The problem is what is "major"? I do releases only when there are enough improvements
anyway, so all the releases are major in some way. The date-based format avoids this
need for subjective judgment, that is why I like it.

ondrej.certik said, at 2008-12-02T13:12:16.000Z:

> What is the problem with the Debian packaging scripts as long as the version number
> is increasing, i.e. the "next version string" > "previous version string"?

They tell the package maintainer when new upstream is available. You do that by
having this file in the debian dir:

$ cat debian/watch
version=3
http://cython.org/Cython-(.*)\.tar.gz

I now for sure, it works as expected for x.y.z versioning scheme, because that is the
de facto standard. Maybe it works for 2008.x as well (why not actually, right?), so
probably all is ok.

robert.cimrman said, at 2008-12-04T10:09:35.000Z:

ok, let's try 2008.4, to be released today. I will let you know to test the tarball
before I make the announcement, right?

robert.cimrman said, at 2008-12-04T15:50:35.000Z:

released.