Re: [Tails-dev] Release versioning
sajolida wrote (02 Dec 2015 09:40:18 GMT) : > intrigeri: >> sajolida wrote (30 Nov 2015 16:39:04 GMT) : >>> - internal (90ad3ac) > This one was actually in summit-2015, but pushed already :) Good! >>> - accounting (8750ec7) All right! Cheers! -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > apparently you are willing to understand better how this works > (otherwise you would not have bothered writing the message I'm > replying to), so here we go: > > sajolida wrote (01 Dec 2015 12:44:46 GMT) : >> I don't know what this UDF is used for as 1.9 will never exist, but >> maybe we should rename it into >> upgrade/v1/Tails/2.0/i386/alpha/upgrades.yml > > Until we merge feature/jessie into devel, all builds from the devel > branch believe that next major release is 1.9, and then running the > test suite on ISOs built from devel still need that UDF. > > Note in passing: we cannot simply *rename* a UDF this way: its content > matters more than the URL, and is authenticated. > >> or create another one for 2.0. > > We always need a UDF for release N+1 immediately after N has been > released (in this case, N=1.8 and N+1=2.0), for the reason > I explained above. > > The good news is that our release process guarantees this invariant, > and I don't think the current situation adds any specific requirement > of its own. > > => I still don't think there's anything to update :) Cool, thanks for all the info. I was also thinking this must be for the test suite or something not user-visible... ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (30 Nov 2015 16:39:04 GMT) : >> Sure, I didn't think about that. So I updated: > >> - master (841af4e) > > Reviewed, OK! > >> - internal (90ad3ac) This one was actually in summit-2015, but pushed already :) >> - accounting (8750ec7) > > Please push these so I can review them :) Done now, sorry... ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, sajolida wrote (30 Nov 2015 16:39:04 GMT) : > Sure, I didn't think about that. So I updated: > - master (841af4e) Reviewed, OK! > - internal (90ad3ac) > - accounting (8750ec7) Please push these so I can review them :) > I also couldn't update the various reports that we already sent to > sponsors mentioning 1.9 and others. So I gave then a conversion table in > 1a753fb. ACK Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, apparently you are willing to understand better how this works (otherwise you would not have bothered writing the message I'm replying to), so here we go: sajolida wrote (01 Dec 2015 12:44:46 GMT) : > I don't know what this UDF is used for as 1.9 will never exist, but > maybe we should rename it into > upgrade/v1/Tails/2.0/i386/alpha/upgrades.yml Until we merge feature/jessie into devel, all builds from the devel branch believe that next major release is 1.9, and then running the test suite on ISOs built from devel still need that UDF. Note in passing: we cannot simply *rename* a UDF this way: its content matters more than the URL, and is authenticated. > or create another one for 2.0. We always need a UDF for release N+1 immediately after N has been released (in this case, N=1.8 and N+1=2.0), for the reason I explained above. The good news is that our release process guarantees this invariant, and I don't think the current situation adds any specific requirement of its own. => I still don't think there's anything to update :) > But I might as well be mistaken and I don't know what UDF for > future versions are for. They're only used by ISOs built from development branches (unless I'm forgetting another usage, which is entirely possible). Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (30 Nov 2015 16:39:04 GMT) : >> So I updated: > >> - master (841af4e) >> - internal (90ad3ac) >> - accounting (8750ec7) > > Thanks! I'll check these one of these days. > > I think fundraising also has some, no? I checked and it had references only in the reports and budgets so I didn't update them on purpose. >> I didn't updated the UDFs as I didn't want to break anything. Can you do >> it? For example: > >> - upgrade/v1/Tails/1.9/i386/alpha/upgrades.yml > > I don't think there's anything to update there; if you think > differently, please tell me what you think should be updated and why > and then I or anonym can do it. I don't know what this UDF is used for as 1.9 will never exist, but maybe we should rename it into upgrade/v1/Tails/2.0/i386/alpha/upgrades.yml or create another one for 2.0. But I might as well be mistaken and I don't know what UDF for future versions are for. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, sajolida wrote (30 Nov 2015 16:39:04 GMT) : > So I updated: > - master (841af4e) > - internal (90ad3ac) > - accounting (8750ec7) Thanks! I'll check these one of these days. I think fundraising also has some, no? > I didn't updated the UDFs as I didn't want to break anything. Can you do > it? For example: > - upgrade/v1/Tails/1.9/i386/alpha/upgrades.yml I don't think there's anything to update there; if you think differently, please tell me what you think should be updated and why and then I or anonym can do it. > I also couldn't update the various reports that we already sent to > sponsors mentioning 1.9 and others. So I gave then a conversion table in > 1a753fb. I'll check this one soonish too. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (27 Nov 2015 12:58:31 GMT) : >> Please review 095e86b and 145da9a. > > Thanks! Added 09d9cde and 255589c on top. > >> Anything else? > > The only missing bit that I can think of is: there are quite a few > occurrences of version numbers that need updating in a few internal > Git repositories of ours. Sure, I didn't think about that. So I updated: - master (841af4e) - internal (90ad3ac) - accounting (8750ec7) I didn't updated the UDFs as I didn't want to break anything. Can you do it? For example: - upgrade/v1/Tails/1.9/i386/alpha/upgrades.yml I also couldn't update the various reports that we already sent to sponsors mentioning 1.9 and others. So I gave then a conversion table in 1a753fb. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, sajolida wrote (27 Nov 2015 12:58:31 GMT) : > Please review 095e86b and 145da9a. Thanks! Added 09d9cde and 255589c on top. > Anything else? The only missing bit that I can think of is: there are quite a few occurrences of version numbers that need updating in a few internal Git repositories of ours. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (26 Nov 2015 13:36:52 GMT) : B. Switch to "even for major releases / odd for minor ones", call the first Tails/Jessie release 2.0, and then > [...] >> I agree with anonym. I don't mind doing the work needed for B. > > Yay, we've got a decision then! > >> And I'm fine with having 2.0 on January 26 and 2.2 on March 8. > > Cool. Please review 095e86b and 145da9a. I also moved all tickets from 1.9 to 2.0 and sent a email about that to everybody. I renamed in Redmine "1.10" into "2.2", "1.11" into "2.3", "1.12" into "2.4", "1.13" into "2.5" and "1.14" into "2.6" in the calendar and in Redmine? Anything else? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
sajolida wrote (26 Nov 2015 13:36:52 GMT) : >>> B. Switch to "even for major releases / odd for minor ones", call the >>>first Tails/Jessie release 2.0, and then [...] > I agree with anonym. I don't mind doing the work needed for B. Yay, we've got a decision then! > And I'm fine with having 2.0 on January 26 and 2.2 on March 8. Cool. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
anonym: > intrigeri: >> intrigeri wrote (18 Aug 2015 11:09:35 GMT) : >>> Please do whatever's needed for the change you proposed in our various >>> repos + Redmine etc., after leaving some time to others to comment >>> further. Perhaps we should make the final decision at the >>> September meeting. >> >> I can't find a follow-up to this discussion. There was none. I didn't hear back from "we should make the final decision at the September meeting" and pinged anonym in private a couple of times. >> To sum up the options we have: >> >> A. Keep "odd for major release / even for minor ones" in general but >>call the first Tails/Jessie release 2.0. Call the next one 2.1 >>because: >>- it'll likely introduce tons of changes to fix bugs in 2.0 anyway >>- 2.0 will be feature-frozen in 2 weeks, so IMO it makes sense to >> have a release with new features allowed in March > > Just wanted to say that I agree to those two points... So you are proposing to have two major releases in a row: January 26 and March 8. This goes beyond mere release versioning so let's agree on this first and then adjust release numbers as we like. Major releases are different minor releases as they imply an RC and more work scheduled for the RM. It seems like both of you agree on doing a major release on March 8. I personally don't mind. >> B. Switch to "even for major releases / odd for minor ones", call the >>first Tails/Jessie release 2.0, and then >>1. find out how to deal with no release with new features allowed >> between November and April; exceptionally allow new features in >> 2.1? > > ... but that's easily achievable by skipping 2.1, i.e. we plan 2.2 six > weeks after 2.0 (in March). Both schemes suffer from the potential need > of release skipping like this, as we already have noticed. Yes, as long as we decide to have consistent semantic between "odd" and "even" (I think intrigeri was strongly in favor of this) while allowing ourselves to put out two majors releases in a row (you're proposing this right now), then all number scheme that we can think of would require us skipping numbers. >>2. adjust whatever is needed for this change > > I could do this, if we decide to switch. > >> As said already I can live with both, but I'd like to see a decision >> made on this soon, and won't do the work required by B. > > I don't care much either. It does make sense that e.g. 2.0 should be a > major release, and that is an even number, so that scheme has that > additional consistency in its favour.. I agree with anonym. I don't mind doing the work needed for B. And I'm fine with having 2.0 on January 26 and 2.2 on March 8. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > Hi, > > intrigeri wrote (18 Aug 2015 11:09:35 GMT) : >> Please do whatever's needed for the change you proposed in our various >> repos + Redmine etc., after leaving some time to others to comment >> further. Perhaps we should make the final decision at the >> September meeting. > > I can't find a follow-up to this discussion. > > To sum up the options we have: > > A. Keep "odd for major release / even for minor ones" in general but >call the first Tails/Jessie release 2.0. Call the next one 2.1 >because: >- it'll likely introduce tons of changes to fix bugs in 2.0 anyway >- 2.0 will be feature-frozen in 2 weeks, so IMO it makes sense to > have a release with new features allowed in March Just wanted to say that I agree to those two points... > B. Switch to "even for major releases / odd for minor ones", call the >first Tails/Jessie release 2.0, and then >1. find out how to deal with no release with new features allowed > between November and April; exceptionally allow new features in > 2.1? ... but that's easily achievable by skipping 2.1, i.e. we plan 2.2 six weeks after 2.0 (in March). Both schemes suffer from the potential need of release skipping like this, as we already have noticed. >2. adjust whatever is needed for this change I could do this, if we decide to switch. > As said already I can live with both, but I'd like to see a decision > made on this soon, and won't do the work required by B. I don't care much either. It does make sense that e.g. 2.0 should be a major release, and that is an even number, so that scheme has that additional consistency in its favour.. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, intrigeri wrote (18 Aug 2015 11:09:35 GMT) : > Please do whatever's needed for the change you proposed in our various > repos + Redmine etc., after leaving some time to others to comment > further. Perhaps we should make the final decision at the > September meeting. I can't find a follow-up to this discussion. To sum up the options we have: A. Keep "odd for major release / even for minor ones" in general but call the first Tails/Jessie release 2.0. Call the next one 2.1 because: - it'll likely introduce tons of changes to fix bugs in 2.0 anyway - 2.0 will be feature-frozen in 2 weeks, so IMO it makes sense to have a release with new features allowed in March B. Switch to "even for major releases / odd for minor ones", call the first Tails/Jessie release 2.0, and then 1. find out how to deal with no release with new features allowed between November and April; exceptionally allow new features in 2.1? 2. adjust whatever is needed for this change As said already I can live with both, but I'd like to see a decision made on this soon, and won't do the work required by B. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, sajolida wrote (13 Aug 2015 19:36:24 GMT) : > intrigeri: >> sajolida wrote (10 Aug 2015 16:48:49 GMT) : >> Please, no: odd for less stable releases is a widely used convention >> in free software, and using a different one is bound to confuse quite >> a few existing and potential contributors (starting with me). > It seems like we are mixing up two different concepts here, one being > "major/minor" and another one being "stable/unstable". I don't think the > "stable/unstable" concept applies to Tails as all releases have the same > lifetime and are ready for production. We don't have the opposite > concept of "development release". This is slightly disputable: our major releases are more prone to introducing regressions than what we used to call point-releases. But I realize that this argument of mine is borderline :) > Since we don't have this concept of stability in Tails it sounds more > logical to me to translate "stable=important" into "major=important". > Important releases being granted even number (such as 1.0). I can live with that. > And makes it more logical to call Tails Jessie > 2.0 without workarounds you described. > But I won't fight over it more than that :) Me neither. Please do whatever's needed for the change you proposed in our various repos + Redmine etc., after leaving some time to others to comment further. Perhaps we should make the final decision at the September meeting. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (10 Aug 2015 16:48:49 GMT) : >> I might have found a bug in our new version numbering scheme... > >> We're saying, regarding the second number, "odd = major" and "even = >> minor". But at the same time "2.0 = major" (or actually super major). >> But zero is even [1]. > > Indeed. I see two potential problems: > > 1. The release after 2.0 will be called 2.1, while technically it's >supposed to be a point-release and not a major one. However, >I suspect that it may contain enough changes (mostly bugfixes) and >important changes that were held back while we're stabilizing >Tails/Jesie, to be worth calling it a major one, so that's not >a blocker IMO. > > 2. People who have understood the new version numbering, trust it to >the letter, *and* ignore the major number bump, will be confused. >I don't think there are many such people, and I don't think it's >a blocker either. > >> Maybe we should consider using "even = minor" and "odd = >> major" instead. > > Please, no: odd for less stable releases is a widely used convention > in free software, and using a different one is bound to confuse quite > a few existing and potential contributors (starting with me). It seems like we are mixing up two different concepts here, one being "major/minor" and another one being "stable/unstable". I don't think the "stable/unstable" concept applies to Tails as all releases have the same lifetime and are ready for production. We don't have the opposite concept of "development release". Since we don't have this concept of stability in Tails it sounds more logical to me to translate "stable=important" into "major=important". Important releases being granted even number (such as 1.0). I read bits of the Wikipedia article on software versioning and understood what you were referring to: - The Linux kernel, used between 1.0 and the 2.6.x "odd minor version numbers to denote development releases and even minor version numbers to denote stable releases". - GNOME which uses even for major and odd for development as well. I feels to me than using "even" for the more important releases and bigger milestones, thus puts us more in sync with GNOME that doing it otherwise for example. And makes it more logical to call Tails Jessie 2.0 without workarounds you described. But I won't fight over it more than that :) ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
hi, sajolida wrote (10 Aug 2015 16:48:49 GMT) : > I might have found a bug in our new version numbering scheme... > We're saying, regarding the second number, "odd = major" and "even = > minor". But at the same time "2.0 = major" (or actually super major). > But zero is even [1]. Indeed. I see two potential problems: 1. The release after 2.0 will be called 2.1, while technically it's supposed to be a point-release and not a major one. However, I suspect that it may contain enough changes (mostly bugfixes) and important changes that were held back while we're stabilizing Tails/Jesie, to be worth calling it a major one, so that's not a blocker IMO. 2. People who have understood the new version numbering, trust it to the letter, *and* ignore the major number bump, will be confused. I don't think there are many such people, and I don't think it's a blocker either. > Maybe we should consider using "even = minor" and "odd = > major" instead. Please, no: odd for less stable releases is a widely used convention in free software, and using a different one is bound to confuse quite a few existing and potential contributors (starting with me). => IMO the drawbacks of calling 2.0 this way don't warrant a versioning scheme change. But if we think that they're serious enough, we could call it 2.1 and be done with it. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
sajolida: > intrigeri: >> sajolida wrote (22 Jun 2015 16:16:07 GMT) : >>> Ok, so what's the next step here? >> >>> - Shall someone sum up all this is in /contribute/release_schedule? >> >> Yes. I've gone through this thread and a quick copy'n'paste summary is: >> >> * always increment the first number with major Debian version >> * also increment the first number whenever it make sense for Tails >>only (user-visible changes) >> * second number: even for bugfix releases, odd for major ones > * we allow ourselves to skip numbers if we release two major or two > minor releases in a row (eg. 1.7 followed by 1.9). >> * add an extra 3rd number for emergency releases I might have found a bug in our new version numbering scheme... We're saying, regarding the second number, "odd = major" and "even = minor". But at the same time "2.0 = major" (or actually super major). But zero is even [1]. Maybe we should consider using "even = minor" and "odd = major" instead. [1]: https://en.wikipedia.org/wiki/Parity_of_zero ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, sajolida wrote (29 Jun 2015 09:52:29 GMT) : >>> This would mean >>> - Updating the calendar >>> - Tweaking Redmine Done. Note that Tails 1.9 or 1.10 will likely be called 2.0 actually, since we'll be migrating to Jessie (and this will also change version numbers for 1.11 and later). But we don't know exactly when yet, so well, we'll see. Perhaps referring to releases *by date* is better for things that are 6+ months in the future. >> + update release process doc, Done. > and possibly some internal documents. Done what I could easily find, but no doubt I've missed some. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri:
> sajolida wrote (22 Jun 2015 16:16:07 GMT) :
>> Ok, so what's the next step here?
>
>> - Shall someone sum up all this is in /contribute/release_schedule?
>
> Yes. I've gone through this thread and a quick copy'n'paste summary is:
>
> * always increment the first number with major Debian version
> * also increment the first number whenever it make sense for Tails
>only (user-visible changes)
> * second number: even for bugfix releases, odd for major ones
* we allow ourselves to skip numbers if we release two major or two
minor releases in a row (eg. 1.7 followed by 1.9).
> * add an extra 3rd number for emergency releases
>
> And regarding milestones ("M" means "milestone" here):
>
> * 2.0 => Sustainability_M1
> * 3.0 => Hardening_M1
>
> Shout if this summary doesn't reflect the consensus that was found.
I'm fine with it and the plan looks great!
>> - when shall we start applying this? 1.5 is the next major and is
>> already an odd number so we're fine. What about starting with
>> renaming 1.5.1 into 1.6?
>
> Makes sense.
>
>> This would mean
>> - Updating the calendar
>> - Tweaking Redmine
>
> + update release process doc, and possibly some internal documents.
>
>> I'd say this can go in the release manager role, but other people
>> can do it as well (starting with me).
>
> I'll try to do that shortly after 1.4.1 is out, but no promise.
Thanks!
--
sajolida
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
hi,
sajolida wrote (22 Jun 2015 16:16:07 GMT) :
> Ok, so what's the next step here?
> - Shall someone sum up all this is in /contribute/release_schedule?
Yes. I've gone through this thread and a quick copy'n'paste summary is:
* always increment the first number with major Debian version
* also increment the first number whenever it make sense for Tails
only (user-visible changes)
* second number: even for bugfix releases, odd for major ones
* add an extra 3rd number for emergency releases
And regarding milestones ("M" means "milestone" here):
* 2.0 => Sustainability_M1
* 3.0 => Hardening_M1
Shout if this summary doesn't reflect the consensus that was found.
> - when shall we start applying this? 1.5 is the next major and is
> already an odd number so we're fine. What about starting with
> renaming 1.5.1 into 1.6?
Makes sense.
> This would mean
> - Updating the calendar
> - Tweaking Redmine
+ update release process doc, and possibly some internal documents.
> I'd say this can go in the release manager role, but other people
> can do it as well (starting with me).
I'll try to do that shortly after 1.4.1 is out, but no promise.
Cheers,
--
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (04 Jun 2015 12:17:13 GMT) : >> I think we should always increment the first number with major Debian >> version, and we could additional increment it whenever it make sense for >> Tails only. But the first number should mean "important changes pushed >> to the user". > > ACK Ok, so what's the next step here? - Shall someone sum up all this is in /contribute/release_schedule? - when shall we start applying this? 1.5 is the next major and is already an odd number so we're fine. What about starting with renaming 1.5.1 into 1.6? This would mean - Updating the calendar - Tweaking Redmine I'd say this can go in the release manager role, but other people can do it as well (starting with me). -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
sajolida wrote (04 Jun 2015 12:33:23 GMT) : >>> Regarding what we have been doing on our roadmap for 2.0 and 3.0 (give >>> them broad objectives) we could maybe do the same again: give us broad >>> directions for our work within a Debian lifetime. >> >> I don't really understand what this idea/proposal means in practice. > We defined 2.0 and 3.0 maybe three years ago and we still don't know > when we'll get there. My proposal here is to have more "time-based" > objectives and define broad objectives in sync with Debian lifetime. But > I think this is outside of the scope of this discussion. Ah, OK. Indeed. Summit agenda++, maybe? :) Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
sajolida wrote (04 Jun 2015 12:17:13 GMT) : > I think we should always increment the first number with major Debian > version, and we could additional increment it whenever it make sense for > Tails only. But the first number should mean "important changes pushed > to the user". ACK ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > sajolida wrote (01 Jun 2015 11:31:18 GMT) : >> ... or change from odd/even to even/odd. If we consider that this is >> only meaningful internally and only happens on rare occasions. >> Skipping a number might feel weird to users, but I think it's no big >> deal either. > > I would personally really dislike having to deal with > odd/even->even/odd changes of meaning. The ability to easily tell if > a past or future release was or will be a major or a minor one is > critical to me for planning work, deliverables, etc. Of course I'm > totally biased on this one, but I feel it's much more important that > some minor weirdness for user-visible version numbers: I bet 99% of > the users don't care about version numbers, and don't understand their > meaning anyway, while these numbers impact a lot our daily work. It seems like this point of disagreement didn't prevent us from finding a compromise. Probably version numbers are most often meaningful and useful to developers only (especially in the free software world) but I think that when used right they can also be a powerful communication tool towards the user. The release of Tails 1.0 made quite a buzz without us doing much and with no crazy new features. I can remember the days I learned that Firefox 1.0 was out and how exciting it was. I also remember Debian release names from years ago and the stuff we organized to celebrate them. I remember how every version of Windows I used look liked, etc. >> I'm also tempted to propose changing the first number with major Debian >> versions (we already almost did that for Tails Wheezy). The way we deal >> with it right now is not really related to what the user experiences as >> a "big change" as our improvements come in gradually. Still, a change in >> Debian version is both a huge work for us and a big change for the user >> (Tails Wheezy and Jessie both introduce a big change in the appearance >> of the desktop environment, not to mention all the major updates of >> included software). > > I like it. > > I'm tempted to amend this proposal with "first number matches Debian's > major release version", e.g. Tails/Jessie would be Tails 8.0, but I'm > not convinced myself that this would add much value => food for > thought, if you folks find a convincing argument in favour of it, > please state it, but before that happens, no need to explain why it > wouldn't be good. > >> Regarding what we have been doing on our roadmap for 2.0 and 3.0 (give >> them broad objectives) we could maybe do the same again: give us broad >> directions for our work within a Debian lifetime. > > I don't really understand what this idea/proposal means in practice. We defined 2.0 and 3.0 maybe three years ago and we still don't know when we'll get there. My proposal here is to have more "time-based" objectives and define broad objectives in sync with Debian lifetime. But I think this is outside of the scope of this discussion. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
intrigeri: > anonym wrote (03 Jun 2015 11:59:20 GMT) : >> On 06/03/2015 12:38 PM, intrigeri wrote: >>> sajolida wrote (01 Jun 2015 11:31:18 GMT) : anonym: Couldn't we add an extra number only when we do an emergency release? >>> >>> I think we can, and we should. > >> Let's just be clear on that it is the action of adding an extra *last* >> number for emergency releases only that fixes the issue that intrigeri >> originally raised. > > Right. Let's wait a bit for more feedback before making the final > decision. > >> Any way, the point I'm trying to make is, if we do what you propose, >> then we lose the control of the first number, and cannot use it for >> our own visions. Do we care? > > I think we care, which invalidates that crazy idea of mine IMO. I think we should always increment the first number with major Debian version, and we could additional increment it whenever it make sense for Tails only. But the first number should mean "important changes pushed to the user". As you can see, I'm generally more tempted to have version numbers relevant for the user than for us. >>> >>> This seems to be one point we disagree about in theory, but I'm sure >>> we can find consensual solutions when looking at the practical aspects :) > >> I'm in the middle. I think the even/odd scheme already improves the >> situation for our users (e.g. makes them more readable and easier to >> distinguish) even with the *potential* version skipping, so I think it's >> a good compromise. > > +1 That works for me, even/odd scheme and *potential* version skipping sounds like a good compromise. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
anonym wrote (03 Jun 2015 11:59:20 GMT) : > On 06/03/2015 12:38 PM, intrigeri wrote: >> sajolida wrote (01 Jun 2015 11:31:18 GMT) : >>> anonym: >>> Couldn't we add an extra number only when we do an >>> emergency release? >> >> I think we can, and we should. > Let's just be clear on that it is the action of adding an extra *last* > number for emergency releases only that fixes the issue that intrigeri > originally raised. Right. Let's wait a bit for more feedback before making the final decision. > Any way, the point I'm trying to make is, if we do what you propose, > then we lose the control of the first number, and cannot use it for > our own visions. Do we care? I think we care, which invalidates that crazy idea of mine IMO. >>> As you can see, I'm generally more tempted to have version numbers >>> relevant for the user than for us. >> >> This seems to be one point we disagree about in theory, but I'm sure >> we can find consensual solutions when looking at the practical aspects :) > I'm in the middle. I think the even/odd scheme already improves the > situation for our users (e.g. makes them more readable and easier to > distinguish) even with the *potential* version skipping, so I think it's > a good compromise. +1 Cheers! -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
anonym: > That reason wasn't stated, but it is that I too feel it's > important to quickly be able to tell whether a release was/is/will be a > major, bugfix or emergency one. > +1! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On 06/03/2015 12:38 PM, intrigeri wrote: > sajolida wrote (01 Jun 2015 11:31:18 GMT) : >> anonym: >> Couldn't we add an extra number only when we do an >> emergency release? > > I think we can, and we should. Let's just be clear on that it is the action of adding an extra *last* number for emergency releases only that fixes the issue that intrigeri originally raised. >>> We could adopt a "even second number for bugfix releases, odd for >>> major/feature releases" scheme (similar to what Linux used before), >>> which would fit in perfectly with how we have been alternating between >>> them so far (which I quite like and hope we will continue with). For >>> emergency releases the third number would then serve the function you >>> propose for the fourth number. If we ever want to release two major >>> releases in a row, or want to postpone a major release, then we just >>> increment by two. > >> ... or change from odd/even to even/odd. If we consider that this is >> only meaningful internally and only happens on rare occasions. >> Skipping a number might feel weird to users, but I think it's no big >> deal either. > > I would personally really dislike having to deal with > odd/even->even/odd changes of meaning. The ability to easily tell if > a past or future release was or will be a major or a minor one is > critical to me for planning work, deliverables, etc. Of course I'm > totally biased on this one, but I feel it's much more important that > some minor weirdness for user-visible version numbers: I bet 99% of > the users don't care about version numbers, and don't understand their > meaning anyway, while these numbers impact a lot our daily work. Switching between not making a distinction between even and odd numbers is the obvious solution so there was a reason that I picked that weird scheme. That reason wasn't stated, but it is that I too feel it's important to quickly be able to tell whether a release was/is/will be a major, bugfix or emergency one. >> I'm also tempted to propose changing the first number with major Debian >> versions (we already almost did that for Tails Wheezy). The way we deal >> with it right now is not really related to what the user experiences as >> a "big change" as our improvements come in gradually. Still, a change in >> Debian version is both a huge work for us and a big change for the user >> (Tails Wheezy and Jessie both introduce a big change in the appearance >> of the desktop environment, not to mention all the major updates of >> included software). > > I like it. > > I'm tempted to amend this proposal with "first number matches Debian's > major release version", e.g. Tails/Jessie would be Tails 8.0, but I'm > not convinced myself that this would add much value => food for > thought, if you folks find a convincing argument in favour of it, > please state it, but before that happens, no need to explain why it > wouldn't be good. Quite a lot of user-facing changes are to be expected with Debian major upgrades, so incrementing the first number kinda makes sense. For users the 1.0.1 -> 1.1 upgrade was obviously more significant (mostly due to the GNOME 2 -> 3 transition, and no IUK) than 0.23 -> 1.0, or perhaps even any upgrade we ever released. When we release the first Tails based on Jessie, the changes will be similarly big, and it may appear weird if that happens with a tiny bump of the second number. I guess Debian geeks also would appreciate to quickly be able to see what version of Debian that Tails is based on. Of course, given how much we install from testing/sid/backports, that will only be a half-truth. Tails 1.0 was about some sort of feature-completeness according to plans we had worked on for years. While there always will be more Tails-specific improvements we can do, I wonder if we ever will need to do something like that again. Well, perhaps if we do something that fundamentally changes Tails, like Tails/Cubes or similar. Any way, the point I'm trying to make is, if we do what you propose, then we lose the control of the first number, and cannot use it for our own visions. Do we care? >> As you can see, I'm generally more tempted to have version numbers >> relevant for the user than for us. > > This seems to be one point we disagree about in theory, but I'm sure > we can find consensual solutions when looking at the practical aspects :) I'm in the middle. I think the even/odd scheme already improves the situation for our users (e.g. makes them more readable and easier to distinguish) even with the *potential* version skipping, so I think it's a good compromise. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On 06/03/2015 01:51 PM, intrigeri wrote:
> Hi,
>
> anonym wrote (03 Jun 2015 11:22:31 GMT) :
>> On 06/03/2015 12:26 PM, intrigeri wrote:
>>> Note that strictly speaking, we don't need the "Tails_" prefix. Also,
>>> I would find it nice to clearly distinguish the "target versions" that
>>> will be 100% reached on a flag day, and by releasing a given Tails
>>> only (e.g. Tails/Jessie), from the ones that are more general
>>> milestones. So, that could become:
>>>
>>> * 2.0 => Milestone_Sustainability
>>> * 3.0 => Milestone_Hardening
>>> * 4.0 => Tails_Jessie
>>>
>>> Thoughts?
>
>> This makes sense but "Milestone_" feels like a redundant prefix in a
>> field called "Milestone".
>
> Well, the field is called "Target version".
>
>> Do we really need a prefix at all?
>
> Maybe not, but I like the fact that "milestone" expresses something
> that's specific and measurable. I'm afraid that if we drop it, then
> these target version names will look like generic categories to which
> we can add anything that fits into what their name expresses.
Hah! I believe I was just confused because we constantly refer to them
as milestones. So, yeah, I agree with you.
>> Also, for the "general" milestones, I guess they be recurring ones. E.g.
>> the one that's currently called 3.0 is perhaps only an initial push for
>> such related things, but maybe there will be another one. Reusing
>> milestones seems like a bad idea, so perhaps they too can be versioned,
>> e.g.:
>
>> * 2.0 => Sustainability_1.0
>> * 3.0 => Hardening_1.0
>
> Totally makes sense, and even better, it addresses the concern
> I expressed above.
>
> But I'm worried that using such version numbers, especially
> two-components ones in the same range as Tails releases', will be
> confusing,
Yeah, makes sense.
> so my current proposal would be:
>
> * 2.0 => Sustainability_M1
> * 3.0 => Hardening_M1
>
> ("M" means "milestone", I think I've seen that used elsewhere in
> similar contexts)
Sounds great!
Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi,
anonym wrote (03 Jun 2015 11:22:31 GMT) :
> On 06/03/2015 12:26 PM, intrigeri wrote:
>> Note that strictly speaking, we don't need the "Tails_" prefix. Also,
>> I would find it nice to clearly distinguish the "target versions" that
>> will be 100% reached on a flag day, and by releasing a given Tails
>> only (e.g. Tails/Jessie), from the ones that are more general
>> milestones. So, that could become:
>>
>> * 2.0 => Milestone_Sustainability
>> * 3.0 => Milestone_Hardening
>> * 4.0 => Tails_Jessie
>>
>> Thoughts?
> This makes sense but "Milestone_" feels like a redundant prefix in a
> field called "Milestone".
Well, the field is called "Target version".
> Do we really need a prefix at all?
Maybe not, but I like the fact that "milestone" expresses something
that's specific and measurable. I'm afraid that if we drop it, then
these target version names will look like generic categories to which
we can add anything that fits into what their name expresses.
> Also, for the "general" milestones, I guess they be recurring ones. E.g.
> the one that's currently called 3.0 is perhaps only an initial push for
> such related things, but maybe there will be another one. Reusing
> milestones seems like a bad idea, so perhaps they too can be versioned,
> e.g.:
> * 2.0 => Sustainability_1.0
> * 3.0 => Hardening_1.0
Totally makes sense, and even better, it addresses the concern
I expressed above.
But I'm worried that using such version numbers, especially
two-components ones in the same range as Tails releases', will be
confusing, so my current proposal would be:
* 2.0 => Sustainability_M1
* 3.0 => Hardening_M1
("M" means "milestone", I think I've seen that used elsewhere in
similar contexts)
Cheers!
--
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On 06/03/2015 12:26 PM, intrigeri wrote: > anonym wrote (31 May 2015 22:20:13 GMT) : >> * 2.0 => Tails_maintainability >> * 3.0 => Tails_hardening >> * 4.0 => Tails_jessie > > Yay, I like it! > > Note that strictly speaking, we don't need the "Tails_" prefix. Also, > I would find it nice to clearly distinguish the "target versions" that > will be 100% reached on a flag day, and by releasing a given Tails > only (e.g. Tails/Jessie), from the ones that are more general > milestones. So, that could become: > > * 2.0 => Milestone_Sustainability > * 3.0 => Milestone_Hardening > * 4.0 => Tails_Jessie > > Thoughts? This makes sense but "Milestone_" feels like a redundant prefix in a field called "Milestone". Do we really need a prefix at all? Also, for the "general" milestones, I guess they be recurring ones. E.g. the one that's currently called 3.0 is perhaps only an initial push for such related things, but maybe there will be another one. Reusing milestones seems like a bad idea, so perhaps they too can be versioned, e.g.: * 2.0 => Sustainability_1.0 * 3.0 => Hardening_1.0 Just throwing an idea out there. Not sure if I like it, even. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Hi, sajolida wrote (01 Jun 2015 11:31:18 GMT) : > anonym: > I feel more aligned with anonym's position. Works for me too :) > Do we need to have a constant number of positions in the version > number scheme for technical reasons? I don't think so. > Couldn't we add an extra number only when we do an > emergency release? I think we can, and we should. >> We could adopt a "even second number for bugfix releases, odd for >> major/feature releases" scheme (similar to what Linux used before), >> which would fit in perfectly with how we have been alternating between >> them so far (which I quite like and hope we will continue with). For >> emergency releases the third number would then serve the function you >> propose for the fourth number. If we ever want to release two major >> releases in a row, or want to postpone a major release, then we just >> increment by two. > ... or change from odd/even to even/odd. If we consider that this is > only meaningful internally and only happens on rare occasions. > Skipping a number might feel weird to users, but I think it's no big > deal either. I would personally really dislike having to deal with odd/even->even/odd changes of meaning. The ability to easily tell if a past or future release was or will be a major or a minor one is critical to me for planning work, deliverables, etc. Of course I'm totally biased on this one, but I feel it's much more important that some minor weirdness for user-visible version numbers: I bet 99% of the users don't care about version numbers, and don't understand their meaning anyway, while these numbers impact a lot our daily work. >> Here's a "benchmark" between our current scheme, the one you propose >> (x.x.x.x) and the even/odd one I'm toying with, for our actual release >> history since 1.0: [...] > I like it. +1 > I'm also tempted to propose changing the first number with major Debian > versions (we already almost did that for Tails Wheezy). The way we deal > with it right now is not really related to what the user experiences as > a "big change" as our improvements come in gradually. Still, a change in > Debian version is both a huge work for us and a big change for the user > (Tails Wheezy and Jessie both introduce a big change in the appearance > of the desktop environment, not to mention all the major updates of > included software). I like it. I'm tempted to amend this proposal with "first number matches Debian's major release version", e.g. Tails/Jessie would be Tails 8.0, but I'm not convinced myself that this would add much value => food for thought, if you folks find a convincing argument in favour of it, please state it, but before that happens, no need to explain why it wouldn't be good. > Regarding what we have been doing on our roadmap for 2.0 and 3.0 (give > them broad objectives) we could maybe do the same again: give us broad > directions for our work within a Debian lifetime. I don't really understand what this idea/proposal means in practice. > As you can see, I'm generally more tempted to have version numbers > relevant for the user than for us. This seems to be one point we disagree about in theory, but I'm sure we can find consensual solutions when looking at the practical aspects :) Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
anonym wrote (31 May 2015 22:20:13 GMT) : > On 05/31/2015 09:24 AM, intrigeri wrote: >> * we're not very clear what the first component means (1.0 had >>a well-defined meaning, no idea what 2.0 will be; we're currently >>using 2.0 and 3.0 on our roadmap to make mid/long-term perspectives >>and goals more readable to everyone involved, but that doesn't >>mean we'll indeed release ISOs labeled 2.0 and 3.0 when we reach >>them; I know that's confusing, sorry) > I think it would be much nicer to leave the version numbers for actual > releases, and use descriptive milestone names for larger visions that > currently do not have a set Tails release, something like: > * 2.0 => Tails_maintainability > * 3.0 => Tails_hardening > * 4.0 => Tails_jessie Yay, I like it! Note that strictly speaking, we don't need the "Tails_" prefix. Also, I would find it nice to clearly distinguish the "target versions" that will be 100% reached on a flag day, and by releasing a given Tails only (e.g. Tails/Jessie), from the ones that are more general milestones. So, that could become: * 2.0 => Milestone_Sustainability * 3.0 => Milestone_Hardening * 4.0 => Tails_Jessie Thoughts? Cheers! -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
anonym: > On 05/29/2015 05:19 PM, intrigeri wrote: >> Hi, >> >> it popped up to my mind that our current versioning scheme is a bit >> painful whenever we need to insert an unexpected release: e.g. >> when we've put out 1.3.1, it "stole" a version number that was >> "reserved", which can result in some confusion, e.g. when looking up >> planning information in past email. > > Yes, this was quite annoying (i.e. it invalidated the original 1.3.1 > release schedule posted to this list). > >> Perhaps we should call all our expected releases a.b.c, and "bonus" >> intermediary releases a.b.c.d? In the case at hand, instead of 1.3, >> 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1. > > I've been thinking about proposing *exactly* this but I've been unsure > since introducing yet another number make them harder to read Let's face > it, Firefox' and Chrome's version inflation is actually an instance of > KISS. Personally I don't think we have to go that far, and do like to > have a first number signifying significant milestones. I feel more aligned with anonym's position. Do we need to have a constant number of positions in the version number scheme for technical reasons? Couldn't we add an extra number only when we do an emergency release? > I'm wondering how much the knowledge of whether a new Tails release is a > major release or not really matters for users. After all, they should > upgrade no matter what and should always read the release notes since > there could significant changes even in bugfix releases (for security > reasons). Hence it seems like making that distinction is only important > for contributors, who we can expect more from for reading extra meaning > in the version numbers. I was going to propose this as well. Still note that whenever we issue a major release, it gets more media attention, people talk about the new features, etc.. But maybe that's because we advertise them better as well and the press would do the same if we had a odd/even schema. > We could adopt a "even second number for bugfix releases, odd for > major/feature releases" scheme (similar to what Linux used before), > which would fit in perfectly with how we have been alternating between > them so far (which I quite like and hope we will continue with). For > emergency releases the third number would then serve the function you > propose for the fourth number. If we ever want to release two major > releases in a row, or want to postpone a major release, then we just > increment by two. ... or change from odd/even to even/odd. If we consider that this is only meaningful internally and only happens on rare occasions. Skipping a number might feel weird to users, but I think it's no big deal either. > Here's a "benchmark" between our current scheme, the one you propose > (x.x.x.x) and the even/odd one I'm toying with, for our actual release > history since 1.0: > > Current x.x.x.x even/odd Release type > 1.0 1.0 1.0(bugfix) > 1.0.1 1.0.1 1.2(bugfix, a major release was skipped) > 1.1 1.1 1.3(major) > 1.1.1 1.1.1 1.4(bugfix) > 1.1.2 1.1.1.1 1.4.1 (emergency) > 1.2 1.2 1.5(major) > 1.2.1 1.2.1 1.6(bugfix) > 1.2.2 1.2.1.1 1.6.1 (emergency) > 1.2.3 1.2.2 1.8(bugfix, a major release was skipped) > 1.3 1.3 1.9(major) > 1.3.1 1.3.0.1 1.9.1 (emergency) > 1.3.2 1.3.1 1.10 (bugfix) > 1.4 1.4 1.11 (major) I like it. I'm also tempted to propose changing the first number with major Debian versions (we already almost did that for Tails Wheezy). The way we deal with it right now is not really related to what the user experiences as a "big change" as our improvements come in gradually. Still, a change in Debian version is both a huge work for us and a big change for the user (Tails Wheezy and Jessie both introduce a big change in the appearance of the desktop environment, not to mention all the major updates of included software). Regarding what we have been doing on our roadmap for 2.0 and 3.0 (give them broad objectives) we could maybe do the same again: give us broad directions for our work within a Debian lifetime. As you can see, I'm generally more tempted to have version numbers relevant for the user than for us. > IMHO the times around 1.1..1.2.1 in our current scheme and 1.1..1.2.1.1 > in x.x.x.x looks pretty crazy (and we will have the same situation > around 2.1), whereas the even/odd scheme always looks sane in terms of > the amount of numbers. The only strange thing in that one are the jumps > from two skipped major releases (1.1 and 1.7). I think a short > explanation in the release notes would make it pretty clear that users > didn't miss a Tails upgrade if we ever have to do that again. > > Perhaps I'm just beating at a problem that doesn't really exist and > should stop now. :) No matt
Re: [Tails-dev] Release versioning
On 05/31/2015 09:24 AM, intrigeri wrote: > * we're not very clear what the first component means (1.0 had >a well-defined meaning, no idea what 2.0 will be; we're currently >using 2.0 and 3.0 on our roadmap to make mid/long-term perspectives >and goals more readable to everyone involved, but that doesn't >mean we'll indeed release ISOs labeled 2.0 and 3.0 when we reach >them; I know that's confusing, sorry) I think it would be much nicer to leave the version numbers for actual releases, and use descriptive milestone names for larger visions that currently do not have a set Tails release, something like: * 2.0 => Tails_maintainability * 3.0 => Tails_hardening * 4.0 => Tails_jessie Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On 05/29/2015 05:19 PM, intrigeri wrote: > Hi, > > it popped up to my mind that our current versioning scheme is a bit > painful whenever we need to insert an unexpected release: e.g. > when we've put out 1.3.1, it "stole" a version number that was > "reserved", which can result in some confusion, e.g. when looking up > planning information in past email. Yes, this was quite annoying (i.e. it invalidated the original 1.3.1 release schedule posted to this list). > Perhaps we should call all our expected releases a.b.c, and "bonus" > intermediary releases a.b.c.d? In the case at hand, instead of 1.3, > 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1. I've been thinking about proposing *exactly* this but I've been unsure since introducing yet another number make them harder to read Let's face it, Firefox' and Chrome's version inflation is actually an instance of KISS. Personally I don't think we have to go that far, and do like to have a first number signifying significant milestones. I'm wondering how much the knowledge of whether a new Tails release is a major release or not really matters for users. After all, they should upgrade no matter what and should always read the release notes since there could significant changes even in bugfix releases (for security reasons). Hence it seems like making that distinction is only important for contributors, who we can expect more from for reading extra meaning in the version numbers. We could adopt a "even second number for bugfix releases, odd for major/feature releases" scheme (similar to what Linux used before), which would fit in perfectly with how we have been alternating between them so far (which I quite like and hope we will continue with). For emergency releases the third number would then serve the function you propose for the fourth number. If we ever want to release two major releases in a row, or want to postpone a major release, then we just increment by two. Here's a "benchmark" between our current scheme, the one you propose (x.x.x.x) and the even/odd one I'm toying with, for our actual release history since 1.0: Current x.x.x.x even/odd Release type 1.0 1.0 1.0(bugfix) 1.0.1 1.0.1 1.2(bugfix, a major release was skipped) 1.1 1.1 1.3(major) 1.1.1 1.1.1 1.4(bugfix) 1.1.2 1.1.1.1 1.4.1 (emergency) 1.2 1.2 1.5(major) 1.2.1 1.2.1 1.6(bugfix) 1.2.2 1.2.1.1 1.6.1 (emergency) 1.2.3 1.2.2 1.8(bugfix, a major release was skipped) 1.3 1.3 1.9(major) 1.3.1 1.3.0.1 1.9.1 (emergency) 1.3.2 1.3.1 1.10 (bugfix) 1.4 1.4 1.11 (major) IMHO the times around 1.1..1.2.1 in our current scheme and 1.1..1.2.1.1 in x.x.x.x looks pretty crazy (and we will have the same situation around 2.1), whereas the even/odd scheme always looks sane in terms of the amount of numbers. The only strange thing in that one are the jumps from two skipped major releases (1.1 and 1.7). I think a short explanation in the release notes would make it pretty clear that users didn't miss a Tails upgrade if we ever have to do that again. Perhaps I'm just beating at a problem that doesn't really exist and should stop now. :) No matter what, we definitely need a *separate* number for emergency releases. Also, I think we should do a better job at communicating what type (major/bugfix) each release is in the important places where contributors read about or plans, like in the release schedule sent to tails-dev@, our website's schedule, and in Redmine. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Daniel Kahn Gillmor wrote (31 May 2015 03:42:32 GMT) : > Sorry, I probably don't understand the current versioning scheme very > well -- is there canonical documentation i should read about its > semantics? I don't think so. Basically: * we're not very clear what the first component means (1.0 had a well-defined meaning, no idea what 2.0 will be; we're currently using 2.0 and 3.0 on our roadmap to make mid/long-term perspectives and goals more readable to everyone involved, but that doesn't mean we'll indeed release ISOs labeled 2.0 and 3.0 when we reach them; I know that's confusing, sorry) * we increment the second component when we put out what we call a "major" release (new features, mostly -- and a release candidate is needed) * we include a 3rd component for point-releases (bugfixes only, no release candidate) > I would normally guess that a "major release" meant a change in the > first value (e.g. from 1.x to 2.0). I tend to favor the simplest > versioning scheme that provides the semantic flexibility needed by the > project. It's indeed tempting to simplify, drop our current usage of the first component, and increment the first component for every major release. In a year we would be at 5.0, which may raise concerns from folks who don't like e.g. Firefox' version number inflation. I think that for now, I prefer my original proposal that changes semantics in a less drastic way. > This is pretty much bike-shedding, though, and whatever folks are > comfortable with is fine with me. Same. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On Sat 2015-05-30 04:22:00 -0400, intrigeri wrote: > Daniel Kahn Gillmor wrote (29 May 2015 15:51:09 GMT) : >> i'd also be fine with only "reserving" (targeting >> for non-immediate changes) a.b, and treating any a.b.c release as an >> intermediary release. > > This would remove the ability to distinguish major releases (e.g. 1.4 > in our current versioning scheme) from point-releases (e.g. 1.4.1), no? Sorry, I probably don't understand the current versioning scheme very well -- is there canonical documentation i should read about its semantics? I would normally guess that a "major release" meant a change in the first value (e.g. from 1.x to 2.0). I tend to favor the simplest versioning scheme that provides the semantic flexibility needed by the project. This is pretty much bike-shedding, though, and whatever folks are comfortable with is fine with me. --dkg signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
Daniel Kahn Gillmor wrote (29 May 2015 15:51:09 GMT) : > On Fri 2015-05-29 11:19:17 -0400, intrigeri wrote: >> it popped up to my mind that our current versioning scheme is a bit >> painful whenever we need to insert an unexpected release: e.g. >> when we've put out 1.3.1, it "stole" a version number that was >> "reserved", which can result in some confusion, e.g. when looking up >> planning information in past email. >> >> Perhaps we should call all our expected releases a.b.c, and "bonus" >> intermediary releases a.b.c.d? In the case at hand, instead of 1.3, >> 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1. > i'd also be fine with only "reserving" (targeting > for non-immediate changes) a.b, and treating any a.b.c release as an > intermediary release. This would remove the ability to distinguish major releases (e.g. 1.4 in our current versioning scheme) from point-releases (e.g. 1.4.1), no? Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On Fri, 29 May 2015 15:19:43 + (UTC) intrigeri wrote: > Perhaps we should call all our expected releases a.b.c, and "bonus" > intermediary releases a.b.c.d? In the case at hand, instead of 1.3, > 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1. As long as Tails doesn't decide to switch to Firefox or Chrome versioning, I'm good. :) What you're suggesting is completely sensible. "Which version of Tails are you seeing that in?" "Tails 61.0.25223978297" pgpBpVW4CYgqf.pgp Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release versioning
On Fri 2015-05-29 11:19:17 -0400, intrigeri wrote: > it popped up to my mind that our current versioning scheme is a bit > painful whenever we need to insert an unexpected release: e.g. > when we've put out 1.3.1, it "stole" a version number that was > "reserved", which can result in some confusion, e.g. when looking up > planning information in past email. > > Perhaps we should call all our expected releases a.b.c, and "bonus" > intermediary releases a.b.c.d? In the case at hand, instead of 1.3, > 1.3.1 and 1.3.2, this would have given 1.3.0, 1.3.0.1, and 1.3.1. I'd be fine with this; i'd also be fine with only "reserving" (targeting for non-immediate changes) a.b, and treating any a.b.c release as an intermediary release. --dkg ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
