[58] in athena10
Re: debathena-build-common and package version numbers
daemon@ATHENA.MIT.EDU (Tim Abbott)
Mon Jan 28 21:44:18 2008
Date: Mon, 28 Jan 2008 21:43:36 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <200801281724.m0SHOWLV016555@equal-rites.mit.edu>
Message-ID: <Pine.LNX.4.64L.0801282130010.453@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Is there an advantage to option #2? Option #1 seems to take slightly less
work than #2, and I think has the same relevant properties.
-Tim Abbott
On Mon, 28 Jan 2008, Greg Hudson wrote:
> Having committed debathena-build-common, I'm ready to convert the
> Athena packages over to using it. When I do that, I'll need to pick a
> new version number for each package. Options are:
>
> 1. Bump the Debathena version component. The sources aren't
> changing, but the materials bundled with the sources are (the
> output of athena-tarball vs. the raw sources with no
> boilerplate). I'm not sure if that counts or not.
>
> 2. Bump the whole version to 10.0.0-debathena1. Anders wrote early
> on that it is "unwise to lock package versions to the Athena
> release they are part of," and that's not my intent here, but if
> I'm bumping the upstream version number to reflect a change in
> the source, 10.0.0 makes the most sense.
>
> As a variation on #2, I could bump the whole version to 10.0.0 (no
> Debathena component) but I'll assume tabbot and andersk would both
> disagree with that to varying degrees based on past discussions.
>
> Anyway, as usual, I'm bringing this up for discussion here before
> making sweeping changes to the tree.
>
