Messages in this thread | | | Subject | Re: Versioning of tree | From | Måns Rullgård <> | Date | Thu, 21 Oct 2004 17:33:53 +0200 |
| |
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 20 Oct 2004, Len Brown wrote: >> >> On Wed, 2004-10-20 at 02:49, Benjamin Herrenschmidt wrote: >> > >> > After you tag a "release" tree in bk, could you bump the version >> > number right away, with eventually some junk in EXTRAVERSION like >> > "-devel" ? >> >> I'd find this to be really helpful too. There has been this period >> between, say, 2.6.9 and 2.6.10-whatever where my build/install scripts >> scribble over my "reference" kernels. > > Personally, I much rather go the way we have gone, because I don't care > about module versioning nearly as much as I care about bug-report > versioning. And if I hear about a bug with 2.6.10-rc1, I want to know that > it really is at _least_ 2.6.10-rc1, if you see what I mean.. > > Now, personally, I'd actually like to know the exact top-of-tree > changeset, so I've considered having something that saves that one away, > but then we'd need to do something about non-BK users (make the nightly > snapshots squirrell it away somewhere too). That would solve both the > module versioning _and_ the bug-report issue. > > So if somebody comes up with a build script that generates that kind of > extra-version automatically, I'm more receptive. But I don't want to muck > with the version manually in a way that I think is the wrong way around..
Would it work to somewhere in the Makefile check for the existence of a BitKeeper directory, and if it exists run bk with the appropriate arguments and append something to EXTRAVERSION? I'm not quite sure which information is the best to add, though.
-- Måns Rullgård mru@mru.ath.cx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |