Follow-up Comment #6, task #2171 (project savane):
> > 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.
I think you misunderstood me here. I meant "+" as uncommon, the dot is widely
used, e.g. for linux, kde, etc. But it's probably correct that Savane will
stick with the 1.* releases for a long time.
> 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).
Frankly, I don't understand the difference. If the new release just fixes a
bug, the distro has to repackage the code, no matter what. It doesn't make a
difference for them whether we call that 1.1.1 or 1.1+1.
Regarding a (distro) packaged version number of 1.1-2, which corresponds with
our release of 1.1+1, I think that this has to be avoided at all costs: it's
simply too confusing.
> I especially do not want 1.1+1 to look like a new release.
> [...]
Why not? Essentially, it *is* a new release -- a bugfix one, though.
> Making a new release takes a lot of time, needs updates
> everywhere.
It doesn't have to involve all those complex actions for a normal release,
but think of it: you'll need to create a new tarball, sign it, upload it, tag
the stuff in the CVS, and add a news item about the new version. (Add more
stuff I've probably forgotten.)
> > [My blurb about MAJOR.MINOR.PATCH]
> A bit long! What matters with release number is that people
> get an idea of how things evolves. But this is probably
> overkill, dont you think?
Sure. But I intended to make this as clear as possible, to avoid
misunderstandings between us. This topic is already quite complex, in my
opinion :)
For a README or something similar, it should be rephrased and shortened.
> But I agree with your definitions apart the PATCH one, since
> it really looks like a release. While the idea of making
> release containing only trivial bugfixes is not a bad one, we
> currently do not make such release.
So why don't we start doing so? That would already educate our users about
the new version scheme.
> The +1 is more a repackaging with a little change actually
> replacing the release of the same main number.
Hm, I would not replace the former release with the fixed one. Why not
leaving the release in the download area, also for history purposes?
Otherwise, one could argue that all tarballs for Savane (except the current
one) should be deleted, because every user should install the latest
version.
Apart from that, I honestly have difficulties in understanding your
differentiation between a "release" and a "bugfix". Almost all steps for a
release would apply to the bugfix as well, no? (see above, tarball creation
and such)
> Well, I think we'll soon test a 1.0.8+1 -> bug #2839
Urgs. Well, a perfect opportunity to create a Savane 1.0.9 tarball ;-)
_______________________________________________________
Reply to this item at:
<http://gna.org/task/?func=detailitem&item_id=2171>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
