release numbering

[GoogleCodeExporter]

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

Original issue reported on code.google.com by robert.c...@gmail.com on 1 Dec 2008 at 12:12

[GoogleCodeExporter]

My proposal:

"year"."number of release",

like Gentoo does it.

Original comment by vlukes@kme.zcu.cz on 2 Dec 2008 at 10:50

[GoogleCodeExporter]

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.

Original comment by robert.c...@gmail.com on 2 Dec 2008 at 10:59

[GoogleCodeExporter]

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.

Original comment by ondrej.c...@gmail.com on 2 Dec 2008 at 11:15

[GoogleCodeExporter]

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

Original comment by ondrej.c...@gmail.com on 2 Dec 2008 at 11:18

[GoogleCodeExporter]

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 :)

Original comment by robert.c...@gmail.com on 2 Dec 2008 at 11:36

[GoogleCodeExporter]

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.

Original comment by robert.c...@gmail.com on 2 Dec 2008 at 12:09

[GoogleCodeExporter]

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

Original comment by ondrej.c...@gmail.com on 2 Dec 2008 at 1:12

[GoogleCodeExporter]

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?

Original comment by robert.c...@gmail.com on 4 Dec 2008 at 10:09

[GoogleCodeExporter]

released.

Original comment by robert.c...@gmail.com on 4 Dec 2008 at 3:50

• Changed state: Fixed

[GoogleCodeExporter]

Migrated to http://github.com/sfepy/sfepy/issues/68

Original comment by robert.c...@gmail.com on 30 Jan 2012 at 10:25

• Changed state: Migrated