Follow-up Comment #4, task #2171 (project savane):
> If you're concerned about this, I suggest to state quite clearly on the
> project's main page the meaning of version numbers (see below). Granted,
> Savane did use the third digit for new (minor) releases in the past, when
in
> fact the second digit would have been more appropriate. But that does not
> justify the introduction of a new (and uncommon) version separator, in my
> opinion.
I would not really say that was uncommon. Most projects I know follow this
scheme (linux, kde, mozilla firefox, gnome in the past). This scheme just do
not fit to Savane since, there is no real need to distinguish medium and
minor revision.
> Yes, currently. But we'll never know how things will evolve, and sticking
with
> the current widely adopted standard should be a safe bet. Take Debian for
> example: They use the "+" for version numbers like
> "1.0+cvs1.1rc", meaning that the packaged version is the release
> candidate for the (upcoming) 1.1 version fetched from CVS. An example
Savane
> version for Debian of "1.3+1+cvs1.4" would be really irritating.
Not really feasible though. +1 could happen only one packaged releases... and
it would not make sense for us to add +1 to a cvs snapshot, which is not a
release.
> > (I guess that distros could even skip it, it does not really
> > matters for distros.
>
> Hm, if 1.1+1 is an important bugfix for 1.1, which should definitely be
used
> instead of 1.1, then I would expect distros to provide the updated
package
My statement was confusing, let me rephrase it: 1.1+1 would replace the 1.1
in the download area (1.1 would effectively be removed, as we want people
looking for 1.1 to get 1.1+1). Distros would like upgrade their package. But
instead of being forced to package a new release that would be named 1.1.1,
they would repackage the new version probably simply increasing their package
revision, usually coming after a -. So they would move from 1.1-1 to 1.1-2 (or
they could follow or naming convention).
I especially do not want 1.1+1 to look like a new release. That should be
only 1.1 + a bugfix too important to wait the next release. Since we usually
have only a short time to make release, but still I want to release often as
I think it's important for a free software to get updated frequently, we
frequently end up with a minor bug found in the release, the kind of bug that
is not very critical but makes the release unclean. Replacing the package is
not nice: not very glasnost, not nice to the people that download the broken
version not knowing their problem as been dealth with. Making a new release
takes a lot of time, needs updates everywhere.
Since we used x.x.X as revision number, as x.x.X is usually taken as revision
number due to usual practice (and common sense: why suddenly the dot as
separator should take a special meaning when it's between the 2nd and 3nd
part of the version?), it really seems to be impossible to use .X in the way
I want to use +X.
As +X would not break package builds (since + is accepted in version string
with both dpkg and rpm, I think), as +X is used in somehow similar ways (the
example you gave about debian show a similar usage), I think that's what we
should use. Indeed, we could use something else (but I do not what) but the
dot does not seems to be an option.
The common naming policy does not really fits to what we need. Best is I
think to establish our that would be backward compatible. And using dots does
not leave us a chance to get such backward compatible policy.
And indeed, we could explain this policy to users (for instance by adding a
note in a README in the download area). But I anyway suppose that most users
will understand that the version number is 1.1 and that the +1, +2 means
their something added... and that he should get this version as the previous
is anyway not (no longer) in the download area.
Indeed, we would not use +1 to fix a security hole: this is a case where all
users should upgrade and the best to do that is to make a real release with
announcements.
_______________________________________________________
Reply to this item at:
<http://gna.org/task/?func=detailitem&item_id=2171>
_______________________________________________
Message posté via/par Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
