apt-0.5.15lorg3.1-rc2

[Panu Matilainen]

On Tue, 2006-05-16 at 18:08 +0200, Ralf Corsepius wrote:
> 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.

Yeah, the new numbering will be all numeric certainly, and apt ->
apt-rpm makes a lot of sense as well, I suppose that can be considered
as agreed on now.

I'm mostly wondering about the actual version where to jump to, 1.0
sounds a bit high considering various things but then .. it's just a
damn number.

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

I kinda like the kernel versioning scheme, except it "bloats" the
numbers a bit. OTOH who cares :) 

Oh and FYI, I'm seriously considering doing this *now* instead of at the
next "new feature"-release, I started typing cleaned up changelog for
lorg3.1 and there's surprisingly lot of things in there. I'm mostly
trying to get used to the look of apt-rpm-1.0.0.tar.bz2 instead of
apt-0.5.15lorg3.1-rc2.tar.bz2 right now :)


	- Panu -