Re: What warrants a non-maintainer release number?
-----BEGIN PGP SIGNED MESSAGE-----
On 17 Dec 1997, James Troup wrote:
> Michael Alan Dorman <firstname.lastname@example.org> writes:
> > This is part of an email exchange Sven and I had. Simply put, I put
> > in a new alpha binary of dpkg-188.8.131.52 that represented nothing but
> > a recompile to pick up new libg++, ncurses, etc. Sven suggested
> > that this warranted a non-maintainer-release number, whereas I had
> > gotten the idea that non-maintainer-releases suggested code changes.
> I hope Guy will reject that. If the binary changes, the version
> number should change.
This is that way because our package system does not allow several binary
packages for the same source package. But it should.
> Things break if you don't increase the version
> number (e.g. automatic upgrade and bug reporting) and you don't have
> to a source release to do a non-maintainer release, just add a new
> entry to the changelog before you recompile.
Again this is a limitation of our current source|binary packaging scheme.
Does not mean it has to be that way.
> What advantage do you see in *not* changing the version number?
Changing the *source* version number would be a gratuitous change.
Packages coming from the same source should be allowed to share that
common source, without changing it at all. That is the meaning of source.
But we currently include the changelog in the source and make it to refer
both to binary and source changes. This is not very elegant.
It would be really nice to have something like epochs for
binary packages coming from the same source.
hello_1.3-0 (compilation 0) is older than hello_1.3-0 (compilation 1)
and dpkg will see the need to upgrade.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .