From: el es <el_es_cr@yahoo.co.uk>
To: linux-kernel@vger.kernel.org
Subject: Re: Kernel version : what about s.yy.ww.tt scheme ?
Date: Fri, 18 Jul 2008 08:31:48 +0000 (UTC) [thread overview]
Message-ID: <loom.20080718T075647-205@post.gmane.org> (raw)
In-Reply-To: <alpine.DEB.1.10.0807171558450.17859@asgard.lang.hm>
<david <at> lang.hm> writes:
>
> it means that you cannot know what version of the kernel you are getting
> ready to release.
Yes, but when it is at large, everybody would know at a first glance, when it
was released.
>
> today we can talk that we are working on 2.6.27 or 'this feature was
> accepted and will be in 2.6.27' any scheme that uses the date of the
> release means that we can't do this.
>
With current scheme you say 'it will be in next stable mainline', not telling
any predictions when will it happen, as the stable number is only an increment,
not bound to anything but the cycle. Which many people do not understand and/or
do not want to. My numbering is not the date of _projected_ release, but the
actual date (week) when the release happened. And then, the actual week when the
stable hit large.
> I see this as a big problem with a fine-grained date scheme.
>
> if we use the year in a date-based scheme and have a near end-of-year
> release slip into the next year (2008.4 is released in Jan 2009) I don't
> see this as a major problem (the bulk of the work was done in 2008 even if
> the final release hit in 2009) under the current development cycle it's
> not like this will end up with 'version 2009.2 released in 2011' type
> emberrasements.
Yes, my numbering addresses this issue. It is the actual date of release,
encoded week-wise. Any development that is not expected to be 'stable' happens
in 2.mm.ww-rcX where ww is the _last_ stable mainline, frozen. Then, at first
glance you can tell 'Oh, your tree is 3 months older than mine, please rebase
before I pull it' or 'Oh, I need to rebase my tree 'cause I haven't done that
for 4 months' sort of things. Even the automated tools have it easier to tell
you when you push a tree 'Your tree is soooo out of date. Do you really want to
push your stale code to somebody else ?' or 'That tree you're pulling, was last
rebased on code created last year. You sure you want it ?'. Just hypothetically.
>
> David Lang
>
el es
[the 'what' in the topic is a thinko, but I don't want to spoil the thread]
next prev parent reply other threads:[~2008-07-18 8:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 8:51 el es
2008-07-17 9:48 ` Jan Engelhardt
2008-07-17 10:38 ` el es
2008-07-17 14:27 ` Justin Mattock
2008-07-18 9:12 ` Jan Engelhardt
2008-07-18 16:24 ` Justin Mattock
2008-07-20 18:14 ` Willy Tarreau
2008-07-21 7:57 ` el es
2008-07-21 9:18 ` david
2008-07-22 12:30 ` el es
2008-07-17 23:02 ` david
2008-07-18 8:31 ` el es [this message]
2008-07-18 15:24 ` Kernel version : what about YYYY.MM.[01].x ? Athanasius
2008-07-22 15:18 ` el es
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20080718T075647-205@post.gmane.org \
--to=el_es_cr@yahoo.co.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®