> 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 "channel" for people to stick to, but that makes sense. On Mon, 17 Sep 2012 17:56:47 -0400 "Derek Atkins" <[email protected]> wrote: > > How about MAJOR.MINOR.PL.DATESTAMP? E.g. 1.6.2.120917 This should > upgrade from 1.6.1, or even 1.6.2, but 1.6.3 should be "newer" > > Does this not work? 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 number of version segments, or something? -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
