[arch-dev-public] ISO Bug Release naming scheme
Hey all, This is something that was never really discussed outright, so it's time to bring it up. Wel all agreed on a YYYY.MM naming scheme for our isos, but tacking on a release number (for bug fixes) makes it look like a day (in date format). Assuming we won't have bug releases is short sighted, so I think we should discuss a proper format for this, as it was never covered. Personally, I like: YYYY.MM-RELEASE for _all_ release. So the next kernel release would be: 2007.10-1 Opinions? Thanks, Aaron
On 9/18/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Hey all, This is something that was never really discussed outright, so it's time to bring it up.
Wel all agreed on a YYYY.MM naming scheme for our isos, but tacking on a release number (for bug fixes) makes it look like a day (in date format).
Assuming we won't have bug releases is short sighted, so I think we should discuss a proper format for this, as it was never covered.
Personally, I like:
YYYY.MM-RELEASE
for _all_ release. So the next kernel release would be:
2007.10-1
Opinions?
This seems to fit the way we do package versioning as well. Hopefully the vast majority of our releases never see a version past 1. What do we do in the last case, however? Should the ISO have been re-dated to the current month? Although our planned releases are following the kernel, there seems to be no need to keep our release numbers following the kernel (which they truly aren't anyway). -Dan
On 9/18/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 9/18/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Hey all, This is something that was never really discussed outright, so it's time to bring it up.
Wel all agreed on a YYYY.MM naming scheme for our isos, but tacking on a release number (for bug fixes) makes it look like a day (in date format).
Assuming we won't have bug releases is short sighted, so I think we should discuss a proper format for this, as it was never covered.
Personally, I like:
YYYY.MM-RELEASE
for _all_ release. So the next kernel release would be:
2007.10-1
Opinions?
This seems to fit the way we do package versioning as well. Hopefully the vast majority of our releases never see a version past 1.
That's what I was thinking too.
What do we do in the last case, however? Should the ISO have been re-dated to the current month? Although our planned releases are following the kernel, there seems to be no need to keep our release numbers following the kernel (which they truly aren't anyway).
Good point. Hmmm. I dunno, I mean we should differentiate between a new kernel ISO and a bug release ISO. Somehow. I think changing the YYYY.MM when the kernel changes, and the -X on a bug fix release is a valid indicator.
Good point. Hmmm. I dunno, I mean we should differentiate between a new kernel ISO and a bug release ISO. Somehow. I think changing the YYYY.MM when the kernel changes, and the -X on a bug fix release is a valid indicator.
Agreement ++
Wednesday 19 September 2007, Aaron Griffin wrote: | YYYY.MM-RELEASE | | for _all_ release. So the next kernel release would be: | | 2007.10-1 makes sense! - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Am Mittwoch, 19. September 2007 schrieb Damir Perisa:
Wednesday 19 September 2007, Aaron Griffin wrote: | YYYY.MM-RELEASE | | for _all_ release. So the next kernel release would be: | | 2007.10-1
makes sense!
- D
+1 one from me i like it too :) greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 9/19/07, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Mittwoch, 19. September 2007 schrieb Damir Perisa:
Wednesday 19 September 2007, Aaron Griffin wrote: | YYYY.MM-RELEASE | | for _all_ release. So the next kernel release would be: | | 2007.10-1
makes sense!
- D
+1 one from me i like it too :)
Great. Thanks a lot guys. Just because I'm an idiot about this stuff, and it's not written down anywhere - what is the official file name of the isos, going forward. I believe there was confusion as to whether the 'codename' would be in the file or not. I thought we agreed in the dev meeting to keep the filenames clean (something like archlinux-YYYY.MM-REL.iso or similar), but I may be wrong, that was a while ago. Could you enlighten me please? - Aaron
Wednesday 19 September 2007, Aaron Griffin wrote: | I thought we agreed in the dev meeting to keep the filenames clean | (something like archlinux-YYYY.MM-REL.iso or similar), but I may | be wrong, that was a while ago. i do not remember as well, but archlinux-YYYY.MM-REL-TYPE-ARCH.iso where TYPE is core/ftp/cd/dvd/full/... (core=only core, ftp=ftpinstall, cd=max690MB, dvd=max4.6GB, full=everything we have) speaking about: can we also make a standard about how the REL will increase? dev.{1...} for internal (dev only releases, non-public) testing.{1...} for testing isos (public) 1 for the release {2..x} for bugfixes, increasing in real numbers so that the end user sees only REL as real number, whereas testers and devs (people more involved and less PR-important) releases are marked clearly. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
2007/9/19, Damir Perisa <damir.perisa@solnet.ch>:
Wednesday 19 September 2007, Aaron Griffin wrote: | I thought we agreed in the dev meeting to keep the filenames clean | (something like archlinux-YYYY.MM-REL.iso or similar), but I may | be wrong, that was a while ago.
i do not remember as well, but
archlinux-YYYY.MM-REL-TYPE-ARCH.iso
where TYPE is core/ftp/cd/dvd/full/... (core=only core, ftp=ftpinstall, cd=max690MB, dvd=max4.6GB, full=everything we have)
speaking about: can we also make a standard about how the REL will increase?
dev.{1...} for internal (dev only releases, non-public) testing.{1...} for testing isos (public) 1 for the release {2..x} for bugfixes, increasing in real numbers so that the end user sees only REL as real number, whereas testers and devs (people more involved and less PR-important) releases are marked clearly.
OK, I've missed the whole discussion so I have few questions: 1) YYYY.MM will stay the same as when the kernel was released, i.e. the bugfix for 2007.10-1 release will be 2007.10-2 even if it will be in November? I think it is OK as it clearly states that they are using the same kernel (and they will have the same codename). 2) What's wrong with YYYY.MM = release, YYYY.MM.{1,2,3,...} - bugfix release (e.g. 2007.08 and 2007.08.1)? Sorry, I don't want to start another round of discussion, I'm just curious. -- Roman Kyrylych (Роман Кирилич)
Wednesday 19 September 2007, Roman Kyrylych wrote: | 2) What's wrong with YYYY.MM = release, YYYY.MM.{1,2,3,...} - | bugfix release (e.g. 2007.08 and 2007.08.1)? [damir@Apollon ~]$ date +%F 2007-09-19 the iso format is YYYY-MM-DD the release numbers may be confused for days. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Am Mittwoch, 19. September 2007 09:49:21 schrieb Roman Kyrylych:
1) YYYY.MM will stay the same as when the kernel was released, i.e. the bugfix for 2007.10-1 release will be 2007.10-2 even if it will be in November? I think it is OK as it clearly states that they are using the same kernel (and they will have the same codename).
If its released in November it should be named 2007.11. Don't forget: if we generate a new iso all new packages from [core] are included. So in most cases there are not only changes to the installer but to the included packages as well. If we release several isos per month (we should really avoid this) its ok to append -X. Pierre -- archlinux.de
2007/9/19, Pierre Schmitz <pierre@archlinux.de>:
Am Mittwoch, 19. September 2007 09:49:21 schrieb Roman Kyrylych:
1) YYYY.MM will stay the same as when the kernel was released, i.e. the bugfix for 2007.10-1 release will be 2007.10-2 even if it will be in November? I think it is OK as it clearly states that they are using the same kernel (and they will have the same codename).
If its released in November it should be named 2007.11. Don't forget: if we generate a new iso all new packages from [core] are included. So in most cases there are not only changes to the installer but to the included packages as well.
If we release several isos per month (we should really avoid this) its ok to append -X.
But with this scheme there's no way to know if new ISO includes new major version of kernel, or this is just a bugfix release. I guess the only way to differentiate major releases from bugfix releases is a codename. -- Roman Kyrylych (Роман Кирилич)
Wow. This clearly got a little bike-sheddy here. I'm sure we all have much better things to do with our time than to read and discuss the ISO naming scheme. Here's the thing: a) YYYY.MM.X as a bug release just doesn't work for the reasons Damir pointed out - it looks like a day. Maybe I'm alone here, but if I can change one character and prevent all of us from answering this question over and over, I'm glad to do it. "Why is it 2007.12.3 when it's the 24th today?" b) -testing.1, -dev.4, etc... I think we're trying to overspec this. Here's a simple solution. If we want internal release, let's use the dot notation that Damir suggest, but why not simply start with rel 0? 2007.12-0.3 -> released as 2007.12-1 2007.12-3.7 -> released as 2007.12-4 We _already_ use the dot notation unofficially for the exact same thing. Again, we're simply alleviating lots of confusion and explanation here. Let's just pick one and be done with this - Jason, Dale, JGC, what do you guys think?
2007/9/19, Aaron Griffin <aaronmgriffin@gmail.com>:
Wow. This clearly got a little bike-sheddy here. I'm sure we all have much better things to do with our time than to read and discuss the ISO naming scheme.
Nope, I'm just trying to find a scheme that clearly differentiate a"major" release from a bugfix release.
Here's the thing: a) YYYY.MM.X as a bug release just doesn't work for the reasons Damir pointed out - it looks like a day.
Arch users are not stupid. ;-) We can even make it 2007.10-2, or 2007.10b etc.
Maybe I'm alone here, but if I can change one character and prevent all of us from answering this question over and over, I'm glad to do it. "Why is it 2007.12.3 when it's the 24th today?"
b) -testing.1, -dev.4, etc... I think we're trying to overspec this.
agree.
Here's a simple solution. If we want internal release, let's use the dot notation that Damir suggest, but why not simply start with rel 0?
2007.12-0.3 -> released as 2007.12-1 2007.12-3.7 -> released as 2007.12-4
We _already_ use the dot notation unofficially for the exact same thing. Again, we're simply alleviating lots of confusion and explanation here.
I only want to make the naming scheme clear for *this* case (that already happened): major release with brand new major kernel version is released on 2007.10. We call it 2007.10.whatever-else-is-coming-here Then there is a bugfix release on November. Should we name it 2007.11.whatever OR 2007.10.some-number-indicating-a-bugfix-release? That's all I'm trying to make clear.
Let's just pick one and be done with this - Jason, Dale, JGC, what do you guys think?
-- Roman Kyrylych (Роман Кирилич)
On Wed, Sep 19, 2007 at 11:08:07AM -0500, Aaron Griffin wrote:
Wow. This clearly got a little bike-sheddy here. I'm sure we all have much better things to do with our time than to read and discuss the ISO naming scheme.
Here's the thing: a) YYYY.MM.X as a bug release just doesn't work for the reasons Damir pointed out - it looks like a day.
Maybe I'm alone here, but if I can change one character and prevent all of us from answering this question over and over, I'm glad to do it. "Why is it 2007.12.3 when it's the 24th today?"
b) -testing.1, -dev.4, etc... I think we're trying to overspec this. Here's a simple solution. If we want internal release, let's use the dot notation that Damir suggest, but why not simply start with rel 0?
2007.12-0.3 -> released as 2007.12-1 2007.12-3.7 -> released as 2007.12-4
We _already_ use the dot notation unofficially for the exact same thing. Again, we're simply alleviating lots of confusion and explanation here.
Let's just pick one and be done with this - Jason, Dale, JGC, what do you guys think?
+1 for a and b. Jason
Jason Chu wrote:
On Wed, Sep 19, 2007 at 11:08:07AM -0500, Aaron Griffin wrote:
Wow. This clearly got a little bike-sheddy here. I'm sure we all have much better things to do with our time than to read and discuss the ISO naming scheme.
Here's the thing: a) YYYY.MM.X as a bug release just doesn't work for the reasons Damir pointed out - it looks like a day.
Maybe I'm alone here, but if I can change one character and prevent all of us from answering this question over and over, I'm glad to do it. "Why is it 2007.12.3 when it's the 24th today?"
b) -testing.1, -dev.4, etc... I think we're trying to overspec this. Here's a simple solution. If we want internal release, let's use the dot notation that Damir suggest, but why not simply start with rel 0?
2007.12-0.3 -> released as 2007.12-1 2007.12-3.7 -> released as 2007.12-4
We _already_ use the dot notation unofficially for the exact same thing. Again, we're simply alleviating lots of confusion and explanation here.
Let's just pick one and be done with this - Jason, Dale, JGC, what do you guys think?
How about actually just using the day? 2007.09.19? I think people can tell when a release is a few days later that not much will have changed except maybe a bugfix. - P
Am Mittwoch, 19. September 2007 18:45:46 schrieb Paul Mattal:
How about actually just using the day? 2007.09.19? I think people can tell when a release is a few days later that not much will have changed except maybe a bugfix.
Or we could just use the unix time stamp: Arch-1190222877.iso. This way we could release up to 60 isos per minute without naming conflicts. :-) -- archlinux.de
* On Wednesday, September 19 2007, Pierre Schmitz wrote:
Or we could just use the unix time stamp: Arch-1190222877.iso. This way we could release up to 60 isos per minute without naming conflicts. :-)
I don't know if it's silly, but I actually don't mind this at all. Though almost our entire user base will be confused by poorly written press releases done on some random site. "ZOMG ArchLinux version 1190222877 has been released!", "ArchLinux Hard at Work with it's Billionth Release!. It'll appear like we've been doing a lot of work between releases as well. lol. // codemac -- .: [ + carpe diem totus tuus + ] :.
Wednesday 19 September 2007, Jeff 'codemac' Mickey wrote: | I don't know if it's silly, but I actually don't mind this at all. | Though almost our entire user base will be confused by poorly | written press releases done on some random site. "ZOMG ArchLinux | version 1190222877 has been released!", "ArchLinux Hard at Work | with it's Billionth Release!. It'll appear like we've been doing a | lot of work between releases as well. every second a potential release! i like the idea... also seriously! :D - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Jeff 'codemac' Mickey wrote:
* On Wednesday, September 19 2007, Pierre Schmitz wrote:
Or we could just use the unix time stamp: Arch-1190222877.iso. This way we could release up to 60 isos per minute without naming conflicts. :-)
I don't know if it's silly, but I actually don't mind this at all. Though almost our entire user base will be confused by poorly written press releases done on some random site. "ZOMG ArchLinux version 1190222877 has been released!", "ArchLinux Hard at Work with it's Billionth Release!. It'll appear like we've been doing a lot of work between releases as well.
While we're painting that bikeshed, I guess we may as well give it another coat. So I'll point out that, although I still think 1 per day is fine, we could do YYYY.MM.DD.HH.SS. I don't think being limited to 1 release per second is really a problem! Meaningful numbers that parse visually but also alphanum sort correctly are cool things. - P
On Wed, Sep 19, 2007 at 03:51:10PM -0400, Paul Mattal wrote:
Jeff 'codemac' Mickey wrote:
* On Wednesday, September 19 2007, Pierre Schmitz wrote:
Or we could just use the unix time stamp: Arch-1190222877.iso. This way we could release up to 60 isos per minute without naming conflicts. :-)
I don't know if it's silly, but I actually don't mind this at all. Though almost our entire user base will be confused by poorly written press releases done on some random site. "ZOMG ArchLinux version 1190222877 has been released!", "ArchLinux Hard at Work with it's Billionth Release!. It'll appear like we've been doing a lot of work between releases as well.
While we're painting that bikeshed, I guess we may as well give it another coat.
That's a great idea! Let's start codenaming our releases colors instead of numbers! I mean, it'll cut down on confusion a lot. We'll never run out of colors for one, so we still have pretty much unlimited release flexibility. Also, the majority of colors don't have apostrophes in them, so we won't have issues with that either! +10 -S
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Simo Leone Verzonden: donderdag 20 september 2007 3:55 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] ISO Release naming scheme
Jeff 'codemac' Mickey wrote:
* On Wednesday, September 19 2007, Pierre Schmitz wrote:
Or we could just use the unix time stamp: Arch-1190222877.iso. This way we could release up to 60 isos per minute without naming conflicts. :-)
I don't know if it's silly, but I actually don't mind this at all. Though almost our entire user base will be confused by poorly written
On Wed, Sep 19, 2007 at 03:51:10PM -0400, Paul Mattal wrote: press
releases done on some random site. "ZOMG ArchLinux version 1190222877 has been released!", "ArchLinux Hard at Work with it's Billionth Release!. It'll appear like we've been doing a lot of work between releases as well.
While we're painting that bikeshed, I guess we may as well give it another coat.
That's a great idea! Let's start codenaming our releases colors instead of numbers! I mean, it'll cut down on confusion a lot. We'll never run out of colors for one, so we still have pretty much unlimited release flexibility. Also, the majority of colors don't have apostrophes in them, so we won't have issues with that either!
+10
-S
Archlinux #ffffff Archlinux #cccccc...
participants (12)
-
Aaron Griffin
-
Damir Perisa
-
Dan McGee
-
eliott
-
Jan de Groot
-
Jason Chu
-
Jeff 'codemac' Mickey
-
Paul Mattal
-
Pierre Schmitz
-
Roman Kyrylych
-
Simo Leone
-
Tobias Powalowski