apt-0.5.15lorg3.1-rc2

Ralf Corsepius rc040203 at freenet.de
Tue May 16 09:08:03 PDT 2006


On Tue, 2006-05-16 at 18:52 +0300, Panu Matilainen wrote:
> On Tue, 2006-05-16 at 17:31 +0200, Ralf Corsepius wrote:
> > On Tue, 2006-05-16 at 18:21 +0300, Panu Matilainen wrote:
> > > Ok, this is now with the filelists fix, no other changes from rc1.
> > > Tested to survive fc4 -> fc5 upgrade calculation which is just about as
> > > acid as a depsolver test gets :) 
> > > 
> > > http://apt-rpm.org/testing/apt-0.5.15lorg3.1-rc2.tar.bz2
> > > 
> > > Please try to give it a spin, I'm planning on putting final lorg3.1 out
> > > this weekend unless something dramatic turns up.
> > Can we please have a more reasonable version numbering?
> > 
> > As you might know, chars and "-" in versions are a PITA to handle.
> 
> Sure, I'm not particularly in love with the current versioning scheme
> and been thinking of doing something about it sooner or later anyway.
> 
> -rcX things are one thing, that's mostly just from old habit and can
> change to something else, no problemo. 
> 
> The more interesting question is the main version number. Currently as
> you probably all know, it's supposed to reflect the debian-apt version
> we're based on + some extra tagging for the -rpm version. Now, we're not
> really following debian apt anymore, there's nothing of interest going
> on in there for rpm systems AFAICT and the stuff on roadmap will take us
> pretty far away from debian-apt eventually. So, the question is what
> random number do we pick :) It needs to be somehow separate from debian
> apt - maybe we should rename the tarball to apt-rpm-<version> to make
> that point clear, then just pick any old version larger than
> 0.5.15lorg3.1 from rpm versioning point of view and go on from there.
> 
> Another related thing is that I've been thinking about having a stable
> and development releases, that's going to need some sort of versioning
> scheme as well - for example uneven numbers for devel-releases and even
> numbers for (supposedly ;) stable ones. That's at least a widely used
> strategy and many people are familiar with it.
> 
> One possibility would be bumping up the version to 1.0 for the stable
> branch to get out of the silly 0.1.2.3.4.5-land and to make it really
> distinct from the debian-apt versioning.
> 
> Ideas, thoughts, comments...? I'm all ears on this one :)
I'd change the package name (e.g. apt-rpm instead of apt), and start all
over with an "all numeric" version numbering.

Which one and how to distinguish "stable" from "devel"/"snapshots" is a
different matter and basically a matter of conventions. Which one to
chose is arbitrary, it only needs to be consistent within a package's
development (c.f. linux kernel, GCC versioning, autoconf/automake info)

I'd use an "all numeric rolling versioning", e.g.

1.0.0 ... stable
1.0.1 ... stable bugfix
1.0.2 ... stable bugfix
...
1.1.0 ... next stable

...
1.0.99.<date> ... devel releases converging towards 1.1.0

[Or if you prefer, use 1.1 instead of 1.0.99 and let it converge towards
1.2.0 (i.e. the Ole' Linux kernel versioning scheme)]

Ralf





More information about the Apt-Rpm mailing list