[Sisuite-devel] SystemImager version naming convention for binary packages

[Bernard Li]

Dear all:

Currently if we are working on say version 3.9.0 and we want to build
development version (i.e. from SVN/nightly), we would tag the SVN
revision number and our names to the RPMs built, eg. 3.9.0r4002_bli.

This causes an issue when the actual release comes about (3.9.0), you
will not be able to upgrade via RPM since 3.9.0r4002_bli is > 3.9.0.

Brian suggested that we do not increment the version until it is ready
for release, eg. if we are working on 3.9.1 release, then we will
build development releases as 3.9.0rXXXX until 3.9.1 is ready to be
tagged.

However, this will not work with 3.9.0, since we cannot go "back" as
3.8.x has a totally different meaning (even minor version is stable,
odd minor version is unstable).

Does anybody else have any comments/suggestions regarding this issue?

I would like to avoid using RPM's epoch if at all possible...

Cheers,

Bernard

[dann frazier]

Post by Bernard Li
However, this will not work with 3.9.0, since we cannot go "back" as
3.8.x has a totally different meaning (even minor version is stable,
odd minor version is unstable).

fyi, dpkg now supports the '~' version component which sorts less than
0. This lets us do things like 3.9.0-1~snapshot.r1234 which is < 3.9.0-1.

[Bernard Li]

Interesting -- when is RPM going to support that :-)

Cheers,

Bernard

Post by dann frazier

Post by Bernard Li
However, this will not work with 3.9.0, since we cannot go "back" as
3.8.x has a totally different meaning (even minor version is stable,
odd minor version is unstable).

fyi, dpkg now supports the '~' version component which sorts less than
0. This lets us do things like 3.9.0-1~snapshot.r1234 which is < 3.9.0-1.
--
dann frazier

[Andrea Righi]

Post by Bernard Li
Currently if we are working on say version 3.9.0 and we want to build
development version (i.e. from SVN/nightly), we would tag the SVN
revision number and our names to the RPMs built, eg. 3.9.0r4002_bli.
This causes an issue when the actual release comes about (3.9.0), you
will not be able to upgrade via RPM since 3.9.0r4002_bli is > 3.9.0.
Brian suggested that we do not increment the version until it is ready
for release, eg. if we are working on 3.9.1 release, then we will
build development releases as 3.9.0rXXXX until 3.9.1 is ready to be
tagged.
However, this will not work with 3.9.0, since we cannot go "back" as
3.8.x has a totally different meaning (even minor version is stable,
odd minor version is unstable).
Does anybody else have any comments/suggestions regarding this issue?
I would like to avoid using RPM's epoch if at all possible...

What about using for example:

VERSION = 3.9.1-0_r4034_arighi
^^

Then, when 3.9.1 comes out rpm will automatically use 3.9.1-1 and it'll
be able to upgrade the 3.9.1-0_r4034_arighi.

-Andrea

[Bernard Li]

Is it possible to set release to 0? Never tried it and never seen it
in practice.

I guess I could try that...

Cheers,

Bernard

Post by Andrea Righi

Post by Bernard Li
Currently if we are working on say version 3.9.0 and we want to build
development version (i.e. from SVN/nightly), we would tag the SVN
revision number and our names to the RPMs built, eg. 3.9.0r4002_bli.
This causes an issue when the actual release comes about (3.9.0), you
will not be able to upgrade via RPM since 3.9.0r4002_bli is > 3.9.0.
Brian suggested that we do not increment the version until it is ready
for release, eg. if we are working on 3.9.1 release, then we will
build development releases as 3.9.0rXXXX until 3.9.1 is ready to be
tagged.
However, this will not work with 3.9.0, since we cannot go "back" as
3.8.x has a totally different meaning (even minor version is stable,
odd minor version is unstable).
Does anybody else have any comments/suggestions regarding this issue?
I would like to avoid using RPM's epoch if at all possible...

VERSION = 3.9.1-0_r4034_arighi
^^
Then, when 3.9.1 comes out rpm will automatically use 3.9.1-1 and it'll
be able to upgrade the 3.9.1-0_r4034_arighi.
-Andrea

[Andrea Righi]

Post by Bernard Li
Is it possible to set release to 0? Never tried it and never seen it
in practice.
I guess I could try that...

Nope. It doesn't work.

You can't include "-" characters in the version and setting release to 0
doesn't resolve, because the pre-release version is always greater than
the final release, i.e. 3.9.1r4048_arighi-0 > 3.9.1-1, because
1r4048_arighi > 1.

So, I switch back and propose a solution similar to the Brian's idea. We
could use odd minor numbers for development/pre-releases and even number
for the official releases.

Example:

3.9.1r4048_arighi will be a 3.9.2 pre-release. After the tag of 3.9.2
we'll use 3.9.3r<svn_release>_<developer> to build 3.9.4 pre-releases,
and so on... What do you think?

-Andrea

PS 3.9.1r4048_arighi is available here:

http://download.systemimager.org/~arighi/systemimager/

It's a nice release candidate for 3.9.1 (or 3.9.2 if we'll use the new
naming style), it would be great if someone could test it...

[Bernard Li]

Hi Andrea:

I guess I'm okay as long as we don't have x.y.0 releases any more :-)

Cheers,

Bernard

Post by Andrea Righi

Post by Bernard Li
Is it possible to set release to 0? Never tried it and never seen it
in practice.
I guess I could try that...

Nope. It doesn't work.
You can't include "-" characters in the version and setting release to 0
doesn't resolve, because the pre-release version is always greater than
the final release, i.e. 3.9.1r4048_arighi-0 > 3.9.1-1, because
1r4048_arighi > 1.
So, I switch back and propose a solution similar to the Brian's idea. We
could use odd minor numbers for development/pre-releases and even number
for the official releases.
3.9.1r4048_arighi will be a 3.9.2 pre-release. After the tag of 3.9.2
we'll use 3.9.3r<svn_release>_<developer> to build 3.9.4 pre-releases,
and so on... What do you think?
-Andrea
http://download.systemimager.org/~arighi/systemimager/
It's a nice release candidate for 3.9.1 (or 3.9.2 if we'll use the new
naming style), it would be great if someone could test it...

[Brian Elliott Finley]

I like it, except may I suggest that we drop the "1r" bit?

In other words, just do this for development releases:

3.9.4048_arighi instead of 3.9.1r4048_arighi
3.9.4053_bli
3.9.4058_focht

Then, when we do a stable release, it turns into:

3.10.0
3.10.1
3.10.2
Etc...

Cheers,

-Brian

Post by Andrea Righi

Post by Bernard Li
Is it possible to set release to 0? Never tried it and never seen it
in practice.
I guess I could try that...

Nope. It doesn't work.
You can't include "-" characters in the version and setting release to 0
doesn't resolve, because the pre-release version is always greater than
the final release, i.e. 3.9.1r4048_arighi-0 > 3.9.1-1, because
1r4048_arighi > 1.
So, I switch back and propose a solution similar to the Brian's idea. We
could use odd minor numbers for development/pre-releases and even number
for the official releases.
3.9.1r4048_arighi will be a 3.9.2 pre-release. After the tag of 3.9.2
we'll use 3.9.3r<svn_release>_<developer> to build 3.9.4 pre-releases,
and so on... What do you think?
-Andrea
http://download.systemimager.org/~arighi/systemimager/
It's a nice release candidate for 3.9.1 (or 3.9.2 if we'll use the new
naming style), it would be great if someone could test it...
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
sisuite-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

[Bernard Li]

Post by Brian Elliott Finley
3.9.4048_arighi instead of 3.9.1r4048_arighi
3.9.4053_bli
3.9.4058_focht
3.10.0
3.10.1
3.10.2
Etc...

How about the situation where I released a development release,
3.9.4053_bli, and at SVN revision 4056 we tagged it as 3.10.0. Then
after that is released, I release a new development release, would
that become 3.10.4057? In that case we cannot have 3.10.1, 3.10.2,
etc... If we are then to do 3.9.4057, then the version would have
gone backwards.

Cheers,

Bernard

[Andrea Righi]

Post by Bernard Li

Post by Brian Elliott Finley
3.9.4048_arighi instead of 3.9.1r4048_arighi
3.9.4053_bli
3.9.4058_focht
3.10.0
3.10.1
3.10.2
Etc...

How about the situation where I released a development release,
3.9.4053_bli, and at SVN revision 4056 we tagged it as 3.10.0. Then
after that is released, I release a new development release, would
that become 3.10.4057? In that case we cannot have 3.10.1, 3.10.2,
etc... If we are then to do 3.9.4057, then the version would have
gone backwards.

well... I wouldn't replace the minor release number with the SVN
version. Now it's used to differentiate a new release with minor
improvements and/or bugfixes and I think it's quite useful to have
contiguous numbers. What about using a kernel style versioning?

Following a proposal of the new developer_guidelines:

== Versioning ==

SystemImager uses a kernel style versioning. Versions are expressed
respecting the following syntax:

VERSION.MAJOR.MINOR[.EXTRAVERSION]

VERSION = major architectural change
MAJOR = major improvements - odd numbers for unstable, even numbers for
stable releases
MINOR = bug fix release or minor improvements - odd numbers for
pre-releases, even numbers for official releases
EXTRAVERSION = development release (based on SVN versions, author, short
feature descriptions, etc.) - optional

Example:

3.9.1.4048_arighi_foo_feature
^ ^ ^ ^
| | | |
| | | SVN version + author + new feature name
| | this is a pre-release of 3.9.2
| unstable branch => next stable will be 3.4.0
Major release

- Official releases doesn't include the EXTRAVERSION number.

- Development patches are accepted only in unstable or development releases.

=== Examples ===

Stable mainline:
3.8.0, 3.8.2, 3.8.4, 3.8.6, ...

Unstable mainline:
3.9.0, 3.9.2, 3.9.4, 3.9.6, ...

Pre-release of the stable mainline:
3.8.1.x_y, 3.8.3.x_y, 3.8.5.x_y, 3.8.7.x_y, ...

A potential version cycle:
* development pre-release: 3.9.1.x_y
* unstable release: 3.9.2
* development pre-release: 3.9.3.x_y
* unstable release: 3.9.4
...
* development pre-release: 3.9.9.x_y
===> * unstable release: 3.9.10 (if it includes development patches)
or
===> * stable release: 3.10.0 (if the version is considered stable)
or
===> * stable release: 4.0.0 (stable and major architectural changes)

-Andrea

[Brian Elliott Finley]

Post by Andrea Righi

Post by Bernard Li

Post by Brian Elliott Finley
3.9.4048_arighi instead of 3.9.1r4048_arighi
3.9.4053_bli
3.9.4058_focht
3.10.0
3.10.1
3.10.2
Etc...

How about the situation where I released a development release,
3.9.4053_bli, and at SVN revision 4056 we tagged it as 3.10.0. Then
after that is released, I release a new development release, would
that become 3.10.4057? In that case we cannot have 3.10.1, 3.10.2,
etc... If we are then to do 3.9.4057, then the version would have
gone backwards.

well... I wouldn't replace the minor release number with the SVN
version. Now it's used to differentiate a new release with minor
improvements and/or bugfixes and I think it's quite useful to have
contiguous numbers.

I'm suggesting that we not replace the minor release number with the SVN
version for *stable* releases. But that we *do* replace the minor release
number with the SVN version + developer initials for the
*development/unstable* releases.


What about using a kernel style versioning?


That is what we have been using, except that I guess the kernel people have
recently changed the way they do versioning.

Post by Andrea Righi
== Versioning ==
SystemImager uses a kernel style versioning. Versions are expressed
VERSION.MAJOR.MINOR[.EXTRAVERSION]
VERSION = major architectural change
MAJOR = major improvements - odd numbers for unstable, even numbers for
stable releases
MINOR = bug fix release or minor improvements - odd numbers for
pre-releases, even numbers for official releases
EXTRAVERSION = development release (based on SVN versions, author, short
feature descriptions, etc.) - optional
3.9.1.4048_arighi_foo_feature
^ ^ ^ ^
| | | |
| | | SVN version + author + new feature name
| | this is a pre-release of 3.9.2
| unstable branch => next stable will be 3.4.0
Major release

I presume you mean "next stable will be 3.10.0"?


- Official releases doesn't include the EXTRAVERSION number.



Yes.


- Development patches are accepted only in unstable or development releases.



Yes.


=== Examples ===

Post by Andrea Righi
3.8.0, 3.8.2, 3.8.4, 3.8.6, ...
3.9.0, 3.9.2, 3.9.4, 3.9.6, ...
3.8.1.x_y, 3.8.3.x_y, 3.8.5.x_y, 3.8.7.x_y, ...
* development pre-release: 3.9.1.x_y
* unstable release: 3.9.2
* development pre-release: 3.9.3.x_y
* unstable release: 3.9.4

...

Post by Andrea Righi
* development pre-release: 3.9.9.x_y
===> * unstable release: 3.9.10 (if it includes development patches)
or
===> * stable release: 3.10.0 (if the version is considered stable)
or
===> * stable release: 4.0.0 (stable and major architectural changes)

I'm mostly OK with this, especially if this lines up with the way the kernel
is currently versioned -- I haven't actually researched how they move
through the steps you've described above. Is what you describe above the
same as the way the kernel team uses the version numbers? I'm thinking that
they do stable releases with the extraversion bit still on there.

The one question I would have is:

- Do we need to differentiate between "official development releases"
and "unofficial development releases". I'd say, if it's a development
release, it's always unofficial. And if we need to do a pre-release, we
just do a developer release, and treat it like a release candidate. In
other words, for unstable releases, always use the SVN version + initials in
the third position (no fourth position ever). And for stable releases,
always use the next incremental integer. As stable releases should only be
versioned for bug fixes, I dont' see a need to do pre-releases of bug-fix
releases.

So, this would look like:
Stable mainline:
3.8.0, 3.8.1, 3.8.3 (the 8, as even, indicates stable)

Unstable (no mainline vs. developer -- make all unstables "developer"
releases. A release candidate could use "rc" as the developer initials, if
desired):
3.9.4053_arighi, 3.9.4060_bef, 3.9.4072_rc

Then the next stable release would be:
3.10.0

Next bug fix release:
3.10.1

Next development/unstable release (doesn't matter if it's from a developer
branch, because the svn version has that inherent):
3.11.4073_bli

-Brian


-Andrea

[Andrea Righi]

Post by Brian Elliott Finley
I'm suggesting that we not replace the minor release number with the SVN
version for *stable* releases. But that we *do* replace the minor
release number with the SVN version + developer initials for the
*development/unstable* releases.

OK.

Post by Brian Elliott Finley
What about using a kernel style versioning?
That is what we have been using, except that I guess the kernel people
have recently changed the way they do versioning.

Yes, they added the fourth number (extraversion) to release early new versions
that includes only critical bug fixes. But, in our case we can simply use the
third number for this.

Post by Brian Elliott Finley
* Do we need to differentiate between "official development
releases" and "unofficial development releases". I'd say, if it's
a development release, it's always unofficial.

Agree. A development release will be not available from the official
repository (sourceforge).

Post by Brian Elliott Finley
And if we need to
do a pre-release, we just do a developer release, and treat it
like a release candidate. In other words, for unstable releases,
always use the SVN version + initials in the third position (no
fourth position ever). And for stable releases, always use the
next incremental integer. As stable releases should only be
versioned for bug fixes, I dont' see a need to do pre-releases of
bug-fix releases.

OK, it should be better IMHO to use an anonymous code for the unstable releases
that we upload in the official repository. I mean, the latest unstable is 3.9.0.
I wouldn't like to distribute 3.9.4058_arighi or 3.9.4058_bef, etc.

Better to use for example 3.9.svn4058, that would be a release candidate for
3.10.0, even if it's a bit misleading, because for a human it's not so clear
that 3.9.svn4058 is greater than 3.9.0... while it's more evident that
3.9.1.svn4058 > 3.9.0.

Post by Brian Elliott Finley
3.8.0, 3.8.1, 3.8.3 (the 8, as even, indicates stable)
Unstable (no mainline vs. developer -- make all unstables "developer"
releases. A release candidate could use "rc" as the developer initials,
3.9.4053_arighi, 3.9.4060_bef, 3.9.4072_rc
3.10.0
3.10.1
Next development/unstable release (doesn't matter if it's from a
3.11.4073_bli

So, in conclusion, I'm ok with everything except that I'd prefer to introduce
the extraversion (fourth number) for development/unstable releases for now, to
have a "smooth" migration from the old version style to the new one (since we
have a 3.9.0 under the unstable branch).

Maybe we can fully adopt to the new style as proposed by Brian starting with
3.10.x...

Other opinions?

-Andrea

[Brian Elliott Finley]

I'm ok with that.

-Brian

Post by Andrea Righi

Post by Brian Elliott Finley
I'm suggesting that we not replace the minor release number with the SVN
version for *stable* releases. But that we *do* replace the minor
release number with the SVN version + developer initials for the
*development/unstable* releases.

OK.

Post by Brian Elliott Finley
What about using a kernel style versioning?
That is what we have been using, except that I guess the kernel people
have recently changed the way they do versioning.

Yes, they added the fourth number (extraversion) to release early new versions
that includes only critical bug fixes. But, in our case we can simply use the
third number for this.

Post by Brian Elliott Finley
* Do we need to differentiate between "official development
releases" and "unofficial development releases". I'd say, if it's
a development release, it's always unofficial.

Agree. A development release will be not available from the official
repository (sourceforge).

Post by Brian Elliott Finley
And if we need to
do a pre-release, we just do a developer release, and treat it
like a release candidate. In other words, for unstable releases,
always use the SVN version + initials in the third position (no
fourth position ever). And for stable releases, always use the
next incremental integer. As stable releases should only be
versioned for bug fixes, I dont' see a need to do pre-releases of
bug-fix releases.

OK, it should be better IMHO to use an anonymous code for the unstable releases
that we upload in the official repository. I mean, the latest unstable is 3.9.0.
I wouldn't like to distribute 3.9.4058_arighi or 3.9.4058_bef, etc.
Better to use for example 3.9.svn4058, that would be a release candidate for
3.10.0, even if it's a bit misleading, because for a human it's not so clear
that 3.9.svn4058 is greater than 3.9.0... while it's more evident that
3.9.1.svn4058 > 3.9.0.

Post by Brian Elliott Finley
3.8.0, 3.8.1, 3.8.3 (the 8, as even, indicates stable)
Unstable (no mainline vs. developer -- make all unstables "developer"
releases. A release candidate could use "rc" as the developer initials,
3.9.4053_arighi, 3.9.4060_bef, 3.9.4072_rc
3.10.0
3.10.1
Next development/unstable release (doesn't matter if it's from a
3.11.4073_bli

So, in conclusion, I'm ok with everything except that I'd prefer to introduce
the extraversion (fourth number) for development/unstable releases for now, to
have a "smooth" migration from the old version style to the new one (since we
have a 3.9.0 under the unstable branch).
Maybe we can fully adopt to the new style as proposed by Brian starting with
3.10.x...
Other opinions?
-Andrea

[Brian Elliott Finley]

Post by Bernard Li

Post by Brian Elliott Finley
3.9.4048_arighi instead of 3.9.1r4048_arighi
3.9.4053_bli
3.9.4058_focht
3.10.0
3.10.1
3.10.2
Etc...

How about the situation where I released a development release,
3.9.4053_bli, and at SVN revision 4056 we tagged it as 3.10.0. Then
after that is released, I release a new development release, would
that become 3.10.4057?

No. It would become 3.11.4057_bli


In that case we cannot have 3.10.1, 3.10.2,

Post by Bernard Li
etc... If we are then to do 3.9.4057, then the version would have
gone backwards.
Cheers,
Bernard
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
sisuite-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sisuite-devel