On Mon, 17 Sep 2012 17:12:20 -0500
Andrew Deason wrote:
> That could interfere with versions like 1.6.2.1 that sometimes occur.
> Conceptually I could imagine something like maybe 1.6.2.0.120917, but I
> don't remember what all the various version rules are for deb and rpm.
> And I don't think O
Troy Benjegerdes writes:
> So are we ever going to have a situation where we have 255 nightly
> builds, and we do *not* release a minor update? (say 1.6.2 to 1.6.3?)
Less than three months to go before that would be true of 1.6.2.
> I would argue for a version scheme something like:
> major.m
> > And I don't think OS X can handle more than a certain number of version
> > segments, or something?
>
> OSX is special, but, we already have the problem and define something
> special there.
> What we'd need to do is define everything as an dev version of
> whatever, but then the problem is
>
On Mon, Sep 17, 2012 at 6:12 PM, Andrew Deason wrote:
>> On Mon, September 17, 2012 5:50 pm, Jeffrey Altman wrote:
>> > The challenge is how should version numbers be generated so that
>> > tonight's build will upgrade yesterday's build while not interfering
>> > with the stable release numbering.
Andrew Deason writes:
> I don't think you can make that say something based on 1.6.1, since the
> head of the 1.6.x branch right now is a different branch than 1.6.1. I
> mean, if git-version said something like "this is 1.6.1 plus N patches",
> that would be incorrect. Since, the head of 1.6.x i
On Mon, 17 Sep 2012 17:10:35 -0500
Ken Dreyer wrote:
> > Isn't this what we already have? If you have a source tree that's
> > not exactly the commit for e.g. openafs-stable-1_6_1, you get a
> > string saying how many commits you are from a known point, and a git
> > hash. So, we should be able t
Andrew Deason writes:
> That could interfere with versions like 1.6.2.1 that sometimes occur.
> Conceptually I could imagine something like maybe 1.6.2.0.120917, but I
> don't remember what all the various version rules are for deb and rpm.
> And I don't think OS X can handle more than a certain
> On Mon, September 17, 2012 5:50 pm, Jeffrey Altman wrote:
> > The challenge is how should version numbers be generated so that
> > tonight's build will upgrade yesterday's build while not interfering
> > with the stable release numbering.
Ah, okay, I wasn't thinking of this as like an unstable "
On Mon, Sep 17, 2012 at 3:41 PM, Andrew Deason wrote:
> On Mon, 17 Sep 2012 10:25:38 -0600
> Ken Dreyer wrote:
>
>> I think a good next step would be to decide how we should handle
>> version numbers in snapshot packages. For example: should configure.ac
>> in the 1_6_x branch contain something l
On Mon, September 17, 2012 5:50 pm, Jeffrey Altman wrote:
> On 9/17/2012 5:41 PM, Andrew Deason wrote:
>
>> Isn't this what we already have? If you have a source tree that's not
>> exactly the commit for e.g. openafs-stable-1_6_1, you get a string
>> saying how many commits you are from a known po
On 9/17/2012 5:41 PM, Andrew Deason wrote:
> Isn't this what we already have? If you have a source tree that's not
> exactly the commit for e.g. openafs-stable-1_6_1, you get a string
> saying how many commits you are from a known point, and a git hash. So,
> we should be able to identify exactly
On Mon, 17 Sep 2012 10:25:38 -0600
Ken Dreyer wrote:
> I think a good next step would be to decide how we should handle
> version numbers in snapshot packages. For example: should configure.ac
> in the 1_6_x branch contain something like "1.6.2" or "1.6.2git" right
> now, and a build script could
12 matches
Mail list logo
