Re: [RFC] 3.1 branching
Hi all, while the new convention is agreed-upon and fixed, I'm refreshing this discussion to point to a quite insightful article by Linus Torvalds on the releases issue: http://torvalds-family.blogspot.com/2008/10/on-making-releases.html Ciao! -- /kinkie
Re: [RFC] 3.1 branching
On fre, 2008-09-26 at 13:25 +1200, Amos Jeffries wrote: logdaemon, internal redirectors, and netdb are big component changes. But not squid-wide. Yes. Isolated feature changes. Number of lines added/deleted does not matter much, the complexity is in the amount of changes to existing code. The cleanup merger is much closer to squid-wide surgery as all file includes get touched in some way. That HAS to wait for reformat, layout, and trunk to settle post-branch. You may want to wait with that until 3.1 is stable. But it depends on how much code is moved around. If it's mainly include file changes then probably it won't matter. Haven't followed that project closely so I really can't comment on the nature of the changes. A reasonable complexity estimate is the number of change chunks / (number of files changed + 3) I think. We seem to have an agreement. Now lets get back to code and bug eh? +1 Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
Hi guys, I'll be off the Net for the next 3 days, and thus I won't participate in the follow-up to this discussion. See you on Sunday! Kinkie
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 Ofcourse. trunk continues it's live and 1 restarts when suitable. The .0 releases is not a requirement, but may be useful depending on how the release matures after the branch, which heavily depends on the state of trunk at time of branching. But as soon as you branch the version needs to be labelled X.Y.0, with .1 being the STABLE release. But there does not NEED to be any .0.x release made at all if you as release maintainer do not want to, So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) Nobody has said anything else. The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Well, as soon as you have branched there will be backporting, and occationally forwardporting. Mainly bugfixes, and occationally a feature deemed important enough but which did not make it in time to the branch point but which made it in good time before the .1 STABLE release. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. That's exactly what we are saying. T And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. We have not said anything about any sub-releases after the .1 STABLE release, except for the possibility of a Release Candidate indication in the web site and/or informal announcement. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Yes. Which is an improvement from the current 1.5 year. (which btw started when Squid-3 branched) Regards Henrik
Re: [RFC] 3.1 branching
Henrik Nordstrom wrote: On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 Ofcourse. trunk continues it's live and 1 restarts when suitable. The .0 releases is not a requirement, but may be useful depending on how the release matures after the branch, which heavily depends on the state of trunk at time of branching. But as soon as you branch the version needs to be labelled X.Y.0, with .1 being the STABLE release. But there does not NEED to be any .0.x release made at all if you as release maintainer do not want to, So I should simply say 'X is how we are doing it'? I think not. Kinkie has somehow convinced Alex of a different way of numbering then simply omitting the word 'STABLE', I'm pondering it but need a good reason to agree. So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) Nobody has said anything else. ? the alternative to this I'm arguing against has another layer of formal .N releases. The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Well, as soon as you have branched there will be backporting, and occationally forwardporting. Mainly bugfixes, and occationally a feature deemed important enough but which did not make it in time to the branch point but which made it in good time before the .1 STABLE release. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. That's exactly what we are saying. By my reading, Alex and Kinkie are going on about a whole lot of *.0.N releases required if we don't consider any particular code STABLE. Like they are confusing trunk stabilization with branch stabilization. T And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. We have not said anything about any sub-releases after the .1 STABLE release, except for the possibility of a Release Candidate indication in the web site and/or informal announcement. Alex has indicated his understanding of NO sub-numbering after X.Y.1, which equates to no -RC. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Yes. Which is an improvement from the current 1.5 year. (which btw started when Squid-3 branched) Yes, yes. I agree that 3.0 went badly before people got the momentum going in PRE6. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote: So I should simply say 'X is how we are doing it'? I think not. Kinkie has somehow convinced Alex of a different way of numbering then simply omitting the word 'STABLE', I'm pondering it but need a good reason to agree. No, it's simply that, but keeping the PRE state and reflecting this in the numbering by using .0.X. The other states are dropped from the numbering. 3.1.PRE1 - 3.1.0.1 3.1.PRE2 - 3.1.0.2 3.1.STABLE1 - 3.1.1 And that we keep an indication on the web site on which releases is currently considered stable for production use. (I would guess usually the latest release + maybe one or two patch releases back, depending on what bugs have been fixed) I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) Nobody has said anything else. ? the alternative to this I'm arguing against has another layer of formal .N releases. How? That's exactly what we are saying. By my reading, Alex and Kinkie are going on about a whole lot of *.0.N releases required if we don't consider any particular code STABLE. Like they are confusing trunk stabilization with branch stabilization. There will likely be a couple of iterations from the branchpoint until we are happy to label the release stable. My estimate is 2 such releases. We have not said anything about any sub-releases after the .1 STABLE release, except for the possibility of a Release Candidate indication in the web site and/or informal announcement. Alex has indicated his understanding of NO sub-numbering after X.Y.1, which equates to no -RC. The RC indication is NOT part of the numbering. It's a process. If a release candidate fails for some reason then that release never gets promoted to stable and we move on to the next number. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
Henrik Nordstrom wrote: On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote: So I should simply say 'X is how we are doing it'? I think not. Kinkie has somehow convinced Alex of a different way of numbering then simply omitting the word 'STABLE', I'm pondering it but need a good reason to agree. No, it's simply that, but keeping the PRE state and reflecting this in the numbering by using .0.X. The other states are dropped from the numbering. 3.1.PRE1 - 3.1.0.1 3.1.PRE2 - 3.1.0.2 3.1.STABLE1 - 3.1.1 And that we keep an indication on the web site on which releases is currently considered stable for production use. (I would guess usually the latest release + maybe one or two patch releases back, depending on what bugs have been fixed) Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N Well, I'm a little doubtful but can't argue against that yet. I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) Nobody has said anything else. ? the alternative to this I'm arguing against has another layer of formal .N releases. How? That's exactly what we are saying. By my reading, Alex and Kinkie are going on about a whole lot of *.0.N releases required if we don't consider any particular code STABLE. Like they are confusing trunk stabilization with branch stabilization. There will likely be a couple of iterations from the branchpoint until we are happy to label the release stable. My estimate is 2 such releases. We have not said anything about any sub-releases after the .1 STABLE release, except for the possibility of a Release Candidate indication in the web site and/or informal announcement. Alex has indicated his understanding of NO sub-numbering after X.Y.1, which equates to no -RC. The RC indication is NOT part of the numbering. It's a process. If a release candidate fails for some reason then that release never gets promoted to stable and we move on to the next number. Yes. Still worried that people are mixing the trunk/before stable1/post-stable1 timespans and what can/can't be done. But will leave it and see what happens when we trial this. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote: Henrik Nordstrom wrote: On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 Ofcourse. trunk continues it's live and 1 restarts when suitable. The .0 releases is not a requirement, but may be useful depending on how the release matures after the branch, which heavily depends on the state of trunk at time of branching. But as soon as you branch the version needs to be labelled X.Y.0, with .1 being the STABLE release. But there does not NEED to be any .0.x release made at all if you as release maintainer do not want to, So I should simply say 'X is how we are doing it'? I think not. Kinkie has somehow convinced Alex of a different way of numbering then simply omitting the word 'STABLE', I'm pondering it but need a good reason to agree. I was just going for consensus. Personally, I am fine both with Kinkie+ (0 has a special meaning then come the stable releases) and with mine (just keep releasing until stable) proposals. I do not want the meaningful words like RC or STABLE to be in the version string. And I want a way to release many times with a specific version (not an automated snapshot) before the branch is marked as stable. So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) Nobody has said anything else. ? the alternative to this I'm arguing against has another layer of formal .N releases. I do not think the number of releases will go up or down significantly. From I do not intend to maintain more point of view, all proposals are the same. The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Well, as soon as you have branched there will be backporting, and occationally forwardporting. Mainly bugfixes, and occationally a feature deemed important enough but which did not make it in time to the branch point but which made it in good time before the .1 STABLE release. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. That's exactly what we are saying. By my reading, Alex and Kinkie are going on about a whole lot of *.0.N releases required if we don't consider any particular code STABLE. Like they are confusing trunk stabilization with branch stabilization. Not any particular code. Just the freshly branched code. We can minimize the number of those 4-digit releases if the code stays longer in trunk, but I think you wanted to branch sooner rather than later. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. We have not said anything about any sub-releases after the .1 STABLE release, except for the possibility of a Release Candidate indication in the web site and/or informal announcement. Alex has indicated his understanding of NO sub-numbering after X.Y.1, which equates to no -RC. You are both right. What Henrik is talking about is announcing a given version as release candidate. What you are talking about is not using RC in the version string. There is no contradiction here. To reduce confusion, release candidate should be renamed to something like stable candidate. It is just a phrase used on the web site or mailing list announcement. My primary request is that before we mark a branch as stable, we have numbered development releases (not automated daily snapshots). Earlier development releases will _not_ be stable candidates. The specifics of naming those development releases are less important. HTH, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote: So how do we tell users to try something between 3.1.0 and 3.1.1? Refer to some specific daily snapshot? Kinkie+ scheme would use numbered beta releases: 3.1.0.1, 3.1.0.2, etc. I think numbered releases are better than daily snapshots for asking users to try something: Argh! Somebody committed a bug 5 minutes before the snapshot we thought we would recommend to the user. Let's wait another day and hope that it does not happen again. People! Please do not commit anything because we need a clean daily snapshot!. Thats all in trunk. We are talking numbering systems for the branches. I am talking about the freshly branched branch, not the trunk. Snapshots are fine for the trunk. To which the only commiter should be the branch maintainer. This is a different issue, but I do not think that limiting access is a good idea until the branch becomes stable. When 3.1 is branched (which you want to happen soon), there will be a lot of cleanup work still going on. I see no reason to make that work go through a maintainer. If that is indeed a requirement, we should not branch 3.1 for now. We can make a new clean snapshot at any point if its really warranted, even to the point of calling it a 3.1.0.1 'release' 3 times in one day. Yes, in Kinkie+ scheme, we can. You scheme does not mention 4-digit releases, even for the branch in a development stage. The extra development release layer in Kinkie+ scheme is only used for 3.1.0, never for 3.1.6 or other non-zero releases. This is a contradiction of your earlier how do we tell users to try something between 3.1.0 and 3.1.1? I do not see a contradiction. 3.1.0.x releases are expected. 3.1.1.x releases are not. The 'please try X' request is done as often after 3.1.1 as before. If 3.1.1 is stable, than the number of such requests would be low enough to be satisfied with patches and such. The next official trial point would be 3.1.2. We come back to the problem of until squid is 100% major bug free for all users (now and in future) it never actually qualifies for that 3.1.1 rating. Correct. That is why we want 4-digit releases to test how stable the branched code is. The more stable it gets, the more users will try them, and the more confident we will become that it is indeed stable. At some point, we will release 3.1.1 and mark the branch as stable. Under my scheme, we would not grant such development test points a full version number, they can get a rc1, rc2, etc (or as at present a '20080912') if needed. That was your original proposal, yes. So Kinkie suggests 4-digit development versions. You now re-suggest 3-digit plus rcW for the same purpose. IMO, Kinkie's scheme is better because not all those snapshots are actually release candidates. Again, it is better to leave complex metadata outside of the release version or tag. People seem happy with the release approach and timelines, just not the current bad naming scheme which implies releases are guaranteed STABLE when in fact only a bug fix improvement. Well, there are several problems with the current scheme, but I think we should preserve the notion of a stable state of the branch. It is not a guarantee, but it allows users to select the right branch/version to deploy. In Kinkie+ scheme and in your scheme, the branch is considered stable when 3.1.1 is released. Before that, there are big known bugs. After that, there should not be any and those that appear should get higher fixing priority. The only significant difference I see is that you want folks to use daily snapshots during development stage of the branch and Kinkie wants sub-numbered releases. Yes, pretty much. If you look at the changeset pages for each 3.0 release so far, there are fixes for some very major bugs in there as far as 3.0.STABLE7. Yes, and that is OK. Stability does not guarantee lack of bugs. If we had run a whole cycle of 3.0.0.N (aka 4 years of testing PRE1 - RC2), we would have still probably have released 3.0.1 (aka 3.0.STABLE1) with those bugs in. Or maybe gone straight from 3.0.0.16 to 3.1.0.1 this month Again, there will be no 3.1.0.1. Once the branch is marked as stable, we stop doing intermediate development releases. That is my understanding of what Kinkie and Henrik want, anyway. I don't realistically expect 3.1 to be perfect either. I'd rather have fixed point releases (3.0.1) based on some known workable code, and a pile of sequentially tagged bundles of 'maybe dodgy code' on top for new un-tested bug fixes. Sure, the only need that we need to address for those bundles during non-stable branch development is that the bundle is not controlled by time, but by a human decision to tag/release it. Alex.
Re: [RFC] 3.1 branching
Alex Rousskov wrote: On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote: So how do we tell users to try something between 3.1.0 and 3.1.1? Refer to some specific daily snapshot? Kinkie+ scheme would use numbered beta releases: 3.1.0.1, 3.1.0.2, etc. I think numbered releases are better than daily snapshots for asking users to try something: Argh! Somebody committed a bug 5 minutes before the snapshot we thought we would recommend to the user. Let's wait another day and hope that it does not happen again. People! Please do not commit anything because we need a clean daily snapshot!. Thats all in trunk. We are talking numbering systems for the branches. I am talking about the freshly branched branch, not the trunk. Snapshots are fine for the trunk. To which the only commiter should be the branch maintainer. This is a different issue, but I do not think that limiting access is a good idea until the branch becomes stable. When 3.1 is branched (which you want to happen soon), there will be a lot of cleanup work still going on. I see no reason to make that work go through a maintainer. If that is indeed a requirement, we should not branch 3.1 for now. The merge queues need to be maintained manually. With this branch there are going to be three to process and the more committers, the harder it gets to sync them. Thats ignoring Henriks 2.x queues as well for the cross-port features. When I started it took myself and Henrik a good week combined to sync just the HEAD and 3.0 queues after everybody committed fixes. It still takes me a few hours to check every time Guido commits his Windows bits to 3.0. There were a non-zero number of regressions on both HEAD and branch encountered during the sync. If other committers are needed I think some simple limits are needed to make things easier: * branch commits MUST have a corresponding trunk commit. Branch gets cherry-pick merge from trunk whenever possible. Back-ports if not. * anything comitted that you didn't write. remember the Author: tags. * bug fixes for 3.0 stable still go down through maintainer. * its hands off everybody except nominated maintainer once the stable release is made. Further tweaking can be done in private sub-branches and go in through trunk as normal when needed. Agreed? I'm minded to add 'only the developers who are responsible for a new feature can commit'. But I know there will be others who can fix some bugs too. But please, work down through trunk as a first choice. We can make a new clean snapshot at any point if its really warranted, even to the point of calling it a 3.1.0.1 'release' 3 times in one day. Yes, in Kinkie+ scheme, we can. You scheme does not mention 4-digit releases, even for the branch in a development stage. The extra development release layer in Kinkie+ scheme is only used for 3.1.0, never for 3.1.6 or other non-zero releases. This is a contradiction of your earlier how do we tell users to try something between 3.1.0 and 3.1.1? I do not see a contradiction. 3.1.0.x releases are expected. 3.1.1.x releases are not. The 'please try X' request is done as often after 3.1.1 as before. If 3.1.1 is stable, than the number of such requests would be low enough to be satisfied with patches and such. The next official trial point would be 3.1.2. We come back to the problem of until squid is 100% major bug free for all users (now and in future) it never actually qualifies for that 3.1.1 rating. Correct. That is why we want 4-digit releases to test how stable the branched code is. The more stable it gets, the more users will try them, and the more confident we will become that it is indeed stable. At some point, we will release 3.1.1 and mark the branch as stable. Under my scheme, we would not grant such development test points a full version number, they can get a rc1, rc2, etc (or as at present a '20080912') if needed. That was your original proposal, yes. So Kinkie suggests 4-digit development versions. You now re-suggest 3-digit plus rcW for the same purpose. IMO, Kinkie's scheme is better because not all those snapshots are actually release candidates. Again, it is better to leave complex metadata outside of the release version or tag. People seem happy with the release approach and timelines, just not the current bad naming scheme which implies releases are guaranteed STABLE when in fact only a bug fix improvement. Well, there are several problems with the current scheme, but I think we should preserve the notion of a stable state of the branch. It is not a guarantee, but it allows users to select the right branch/version to deploy. In Kinkie+ scheme and in your scheme, the branch is considered stable when 3.1.1 is released. Before that, there are big known bugs. After that, there should not be any and those that appear should get higher fixing priority. The only significant difference I see is that you want folks to use daily snapshots during development
Re: [RFC] 3.1 branching
On Fri, 2008-09-26 at 05:28 +1200, Amos Jeffries wrote: The merge queues need to be maintained manually. With this branch there are going to be three to process and the more committers, the harder it gets to sync them. Thats ignoring Henriks 2.x queues as well for the cross-port features. When I started it took myself and Henrik a good week combined to sync just the HEAD and 3.0 queues after everybody committed fixes. It still takes me a few hours to check every time Guido commits his Windows bits to 3.0. There were a non-zero number of regressions on both HEAD and branch encountered during the sync. Understood. What do you think is better: A) Branch and commit waiting stuff to trunk now. Deal with a large volume of complicated commit traffic between the 3.1 branch and trunk. B) Branch and commit waiting stuff later. Focus on 3.1 leftovers and stability without being distracted by cross-porting commit traffic. I would pick B, but since you are handling most of the commit traffic, I think it is your choice. If other committers are needed I think some simple limits are needed to make things easier: * branch commits MUST have a corresponding trunk commit. Branch gets cherry-pick merge from trunk whenever possible. Back-ports if not. Agreed. The more new stuff enters trunk, the more time-consuming double-commits will become though. * anything comitted that you didn't write. remember the Author: tags. Can somebody (or do we) use Author for copyright-related statements? If yes, then who wrote the code may be irrelevant in some cases. * bug fixes for 3.0 stable still go down through maintainer. Sure. * its hands off everybody except nominated maintainer once the stable release is made. Further tweaking can be done in private sub-branches and go in through trunk as normal when needed. Agreed. I'm minded to add 'only the developers who are responsible for a new feature can commit'. But I know there will be others who can fix some bugs too. Right. There are many bugs/fixes that have no feature behind them. I'm slightly more than half-convinced. It's much of a sameness as you pointed out. I'm willing to trial it and see how things go for 3.1. Sounds good. (See, Kinkie, it worked this time! :-). I think the only big decision left is whether to branch first or stabilize first. Thank you, Alex.
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote: Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N Well, I'm a little doubtful but can't argue against that yet. No, not quite. There is no point of DEVEL releases in the current form of the development cycle. So we skip those. The nightly snapshots is good enough for that purpose. PRE relesaes is the main needed release while trying to get the branch in shape. These is the 3.1.0.N releases where N = 1. RC using the actual release version. The forst RC for 3.1 would be 3.1.1. And if fine (which it should be) this is the same tarball which then gets promoted to stable for production use. If there is a problem with the RC then there is two choices. Either skip the release number and number the stable release 3.1.2, or reroll 3.1.1. Which one depends on if the RC has been distributed. Quite often RC level errors is detected immediately even before announcing it to squid-dev.. Yes. Still worried that people are mixing the trunk/before stable1/post-stable1 timespans and what can/can't be done. But will leave it and see what happens when we trial this. This thread is only about numbering within a single stable branch. It's separate from trunk policy. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 21:12 +0200, Henrik Nordstrom wrote: On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote: Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N Well, I'm a little doubtful but can't argue against that yet. No, not quite. There is no point of DEVEL releases in the current form of the development cycle. So we skip those. The nightly snapshots is good enough for that purpose. PRE relesaes is the main needed release while trying to get the branch in shape. These is the 3.1.0.N releases where N = 1. RC using the actual release version. The forst RC for 3.1 would be 3.1.1. And if fine (which it should be) this is the same tarball which then gets promoted to stable for production use. I thought we would use RC label for selected/last 4-digit releases. If there is a problem with the RC then there is two choices. Either skip the release number and number the stable release 3.1.2, or reroll 3.1.1. Which one depends on if the RC has been distributed. Quite often RC level errors is detected immediately even before announcing it to squid-dev.. If we use RC label for selected/last 4-digit releases, then we will not have the above problems. If a 4-digit release proves stable, we post 3.1.1 (an exact copy of the last successful 4-digit release, except for the version number) and mark the branch as stable. Is there a reason we cannot have stable candidates using 4-digit versions? Cheers, Alex.
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 08:11 -0600, Alex Rousskov wrote: This is a different issue, but I do not think that limiting access is a good idea until the branch becomes stable. When 3.1 is branched (which you want to happen soon), there will be a lot of cleanup work still going on. I see no reason to make that work go through a maintainer. If that is indeed a requirement, we should not branch 3.1 for now. In the somewhat raw branch maintenance process we have it's important that everyone who commit on a stable branch follow the procedure in tracking the merges, or you'll actually increase the workload of the branch manager. It's better stuff gets committed to HEAD and then asked to have them backported to stable. I have some ideas on some simple tools to fix that, but time is a limiting factor.. The exception is issues which are unique to the stable branch, or which requires effort to backport. Issues unique to the stable branch is generally fine to commit directly there, as that's the startingpoint for tracking that change. For issues requiring effort to backport there is no simple answer. If 3.1.1 is stable, than the number of such requests would be low enough to be satisfied with patches and such. The next official trial point would be 3.1.2. Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not yet on the FTP server or announced on squid-announce, and labelled as an release candidate on the web server. Before that there is also the nightly snapshots which works well for testing of the upcoming release, so the number of times a RC fails should be nearly zero. But it's still a timeframe which is needed to ensure we do not label obviously broken releases as stable. Again, there will be no 3.1.0.1. Once the branch is marked as stable, we stop doing intermediate development releases. That is my understanding of what Kinkie and Henrik want, anyway. Yes. It's pointless during a stable cycle as the number of fixes between the patch releases is quite small, has been tested verified in HEAD and as individual patches or nightly snapshots. The number of times RC releases has been used between STABLE releases in Squid-2 can probably be counted on a single hand, and nearly all times it's been things which really belongs in the next release number and not a patch release. I can only remember one time where it was due to a major bugfix (the 2GB barrier) and even then that's probably more suitable for the next release.. So the main reason why RC releases has been seen between STABLE patch releases is due to the somewhat twisted release process we had for Squid-2 with no further releases forcing these rather major changes to take place during a stable cycle. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 08:40 -0600, Alex Rousskov wrote: I do not want the meaningful words like RC or STABLE to be in the version string. And I want a way to release many times with a specific version (not an automated snapshot) before the branch is marked as stable. Same here, but I am not happy with the first stable release of Squid-3.1 being Squid-3.1.47 which is why I advocate for the .0.x releases to isolate those releases as a artefact not really visible to the end-users once we reach stable. I do not think the number of releases will go up or down significantly. From I do not intend to maintain more point of view, all proposals are the same. Correct. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 21:34 +0200, Henrik Nordstrom wrote: Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not yet on the FTP server or announced on squid-announce, and labelled as an release candidate on the web server. Before that there is also the nightly snapshots which works well for testing of the upcoming release, so the number of times a RC fails should be nearly zero. But it's still a timeframe which is needed to ensure we do not label obviously broken releases as stable. IMO, we do not have enough resources to label releases as stable. We can only label whole branches. That is, I do not think we should do RCs for X.Y.2 and beyond. Once the branch is declared stable, we do our best to keep each release that way. There will be bugs, but we do not have enough resources to RC every supposed-to-be-stable release after the first one (3.1.1). There is nothing wrong with the idea of doing RC for every release on a stable branch. I just do not think we should spend time on that for now. Cheers, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 13:50 -0600, Alex Rousskov wrote: On Thu, 2008-09-25 at 21:34 +0200, Henrik Nordstrom wrote: Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not yet on the FTP server or announced on squid-announce, and labelled as an release candidate on the web server. Before that there is also the nightly snapshots which works well for testing of the upcoming release, so the number of times a RC fails should be nearly zero. But it's still a timeframe which is needed to ensure we do not label obviously broken releases as stable. IMO, we do not have enough resources to label releases as stable. We can only label whole branches. That is, I do not think we should do RCs for X.Y.2 and beyond. Once the branch is declared stable, we do our best to keep each release that way. There will be bugs, but we do not have enough resources to RC every supposed-to-be-stable release after the first one (3.1.1). Actually, RC should be issued for 3.1.0.47, not for 3.1.1. 3.1.1 is just a copy of 3.1.0.47 if the latter was proven to be stable. If not, we post 3.1.0.48. $0.02, Alex.
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote: Understood. What do you think is better: A) Branch and commit waiting stuff to trunk now. Deal with a large volume of complicated commit traffic between the 3.1 branch and trunk. B) Branch and commit waiting stuff later. Focus on 3.1 leftovers and stability without being distracted by cross-porting commit traffic. I would pick B, but since you are handling most of the commit traffic, I think it is your choice. How much of that waiting stuff is major changes touching large parts of the code base? Without any such change the two is close to equal from a stable branch maintenance perspective. What can be seein in Squid-2 is that bugfixes which enters 2.HEAD still migrates pretty much effordless down to 2.6 via 2.7, even when the distance between 2.6 and 2.HEAD is by now quite large. Probably they would merge pretty much effordless very many releases back. * anything comitted that you didn't write. remember the Author: tags. Can somebody (or do we) use Author for copyright-related statements? If yes, then who wrote the code may be irrelevant in some cases. It's for tracking the author mainly. Copyrights is kept within the content, not the merge messages. I think the only big decision left is whether to branch first or stabilize first. My vote: 1. Finish any pending major restucturing/reorganisations/reformmatting first. For example if the code is to be restyled before 3.1 is old and mature then it must be done before 3.1 is branched. Such changes is a major blocker for branching. 2. Branch so 3.1 can start it's road to stabilization in a sensible manner. It does not really matter if it's 100% feature complete, or if there is some already committed features which isn't quite finished. Small features is no different from bugfixes in terms of maintenance, and if it's found there is committed unfinished stuff already in the tree then it can quite easily be bounced to the next release after branching (but not before). Also if now missing features gets further delayed they simply won't make it in time for the release and will get a new chance in the next release (3.2). 3. flame anyone who commits bugfixes embedded within feature commits. Bugfixes need to be separate for the maintenance process to work. Any bugfixes committed as part of feature commits gets hidden and lost from the maintenane process. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote: If we use RC label for selected/last 4-digit releases, then we will not have the above problems. If a 4-digit release proves stable, we post 3.1.1 (an exact copy of the last successful 4-digit release, except for the version number) and mark the branch as stable. Is there a reason we cannot have stable candidates using 4-digit versions? My view on stable after loosing the version tag: stable is something a release earns by proving stable. It's someting a release gets after being released and tested, not by a new release. Applies equal to later patch releases who also start their lives as stable candidates and then gets promoted to stable. Also as major bugs gets discovered now known broken releases may loose their stable stamp. The release candidate process for getting to 3.1.1 is dealt with by the 3.1.0.X releases. The diff between the last 3.1.0.X and 3.1.1 should preferably just be the version number, with that 3.1.0.X being a release candidate for 3.1. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 22:53 +0200, Henrik Nordstrom wrote: On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote: If we use RC label for selected/last 4-digit releases, then we will not have the above problems. If a 4-digit release proves stable, we post 3.1.1 (an exact copy of the last successful 4-digit release, except for the version number) and mark the branch as stable. Is there a reason we cannot have stable candidates using 4-digit versions? My view on stable after loosing the version tag: stable is something a release earns by proving stable. It's someting a release gets after being released and tested, not by a new release. Applies equal to later patch releases who also start their lives as stable candidates and then gets promoted to stable. Also as major bugs gets discovered now known broken releases may loose their stable stamp. The above is too extreme, IMO. We will often have no stable releases if we remain honest and follow the above scheme to the letter: ... 3.1.4 is released; no stable mark by default a bug is found; all previous 3.1 releases lose their stable mark 3.1.5 is released, fixing the bug; no stable mark by default no bugs 3.1.5 is marked as stable (*) a bug is found 3.1.5 loses its stable mark; no 3.1 stable release available again 3.1.6 is released; no stable mark by default ... This means that except for (*) period, users will have to use Squid 3.0 or Squid 2.x (which use less draconian scheme) instead of Squid 3.1. Not a good side-effect. Even worse, consider a user that has a company policy to only run stable versions. That user installs 3.1.5 and then discovers he has to downgrade to 3.0, which lacks the feature he needs. And the serious bug found in 3.1.5 may not even affect that user. That's just plain wrong. I think we should mark _branches_ not individual versions. A stable branch has certain project backing behind it. A stable version does not mean much because bugs can always remove that flag. Said that, if others are convinced that we should try testing and marking each release, I am happy to try it. The release candidate process for getting to 3.1.1 is dealt with by the 3.1.0.X releases. The diff between the last 3.1.0.X and 3.1.1 should preferably just be the version number, with that 3.1.0.X being a release candidate for 3.1. +1 on that. Thank you, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 22:40 +0200, Henrik Nordstrom wrote: My vote: 1. Finish any pending major restucturing/reorganisations/reformmatting first. For example if the code is to be restyled before 3.1 is old and mature then it must be done before 3.1 is branched. Such changes is a major blocker for branching. 2. Branch so 3.1 can start it's road to stabilization in a sensible manner. It does not really matter if it's 100% feature complete, or if there is some already committed features which isn't quite finished. Small features is no different from bugfixes in terms of maintenance, and if it's found there is committed unfinished stuff already in the tree then it can quite easily be bounced to the next release after branching (but not before). Also if now missing features gets further delayed they simply won't make it in time for the release and will get a new chance in the next release (3.2). 3. flame anyone who commits bugfixes embedded within feature commits. Bugfixes need to be separate for the maintenance process to work. Any bugfixes committed as part of feature commits gets hidden and lost from the maintenane process. I am OK with the above, especially if Amos prefers this path. Thank you, Alex.
Re: [RFC] 3.1 branching
On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote: Understood. What do you think is better: A) Branch and commit waiting stuff to trunk now. Deal with a large volume of complicated commit traffic between the 3.1 branch and trunk. B) Branch and commit waiting stuff later. Focus on 3.1 leftovers and stability without being distracted by cross-porting commit traffic. I would pick B, but since you are handling most of the commit traffic, I think it is your choice. How much of that waiting stuff is major changes touching large parts of the code base? logdaemon, internal redirectors, and netdb are big component changes. But not squid-wide. The cleanup merger is much closer to squid-wide surgery as all file includes get touched in some way. That HAS to wait for reformat, layout, and trunk to settle post-branch. Without any such change the two is close to equal from a stable branch maintenance perspective. What can be seein in Squid-2 is that bugfixes which enters 2.HEAD still migrates pretty much effordless down to 2.6 via 2.7, even when the distance between 2.6 and 2.HEAD is by now quite large. Probably they would merge pretty much effordless very many releases back. * anything comitted that you didn't write. remember the Author: tags. Can somebody (or do we) use Author for copyright-related statements? If yes, then who wrote the code may be irrelevant in some cases. It's for tracking the author mainly. Copyrights is kept within the content, not the merge messages. I think the only big decision left is whether to branch first or stabilize first. My vote: 1. Finish any pending major restucturing/reorganisations/reformmatting first. For example if the code is to be restyled before 3.1 is old and mature then it must be done before 3.1 is branched. Such changes is a major blocker for branching. Ditto. Those are down as 'features' blocking branch. Only the src/ folder re-org may cause delays. 2. Branch so 3.1 can start it's road to stabilization in a sensible manner. It does not really matter if it's 100% feature complete, or if there is some already committed features which isn't quite finished. Small features is no different from bugfixes in terms of maintenance, and if it's found there is committed unfinished stuff already in the tree then it can quite easily be bounced to the next release after branching (but not before). Also if now missing features gets further delayed they simply won't make it in time for the release and will get a new chance in the next release (3.2). That last is already on the books. Only eCAP is blocking right now because it was cemented and guaranteed before the flexible feature track was taken. 3. flame anyone who commits bugfixes embedded within feature commits. Bugfixes need to be separate for the maintenance process to work. Any bugfixes committed as part of feature commits gets hidden and lost from the maintenane process. We seem to have an agreement. Now lets get back to code and bug eh? Amos
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 22:40 +0200, Henrik Nordstrom wrote: My vote: 1. Finish any pending major restucturing/reorganisations/reformmatting first. For example if the code is to be restyled before 3.1 is old and mature then it must be done before 3.1 is branched. Such changes is a major blocker for branching. 2. Branch so 3.1 can start it's road to stabilization in a sensible manner. It does not really matter if it's 100% feature complete, or if there is some already committed features which isn't quite finished. Small features is no different from bugfixes in terms of maintenance, and if it's found there is committed unfinished stuff already in the tree then it can quite easily be bounced to the next release after branching (but not before). Also if now missing features gets further delayed they simply won't make it in time for the release and will get a new chance in the next release (3.2). 3. flame anyone who commits bugfixes embedded within feature commits. Bugfixes need to be separate for the maintenance process to work. Any bugfixes committed as part of feature commits gets hidden and lost from the maintenane process. I am OK with the above, especially if Amos prefers this path. +1. Amos
Re: [RFC] 3.1 branching
Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. DEVEL releases is rarely needed as the nightly snapshot releases serves this purpose well. Came to light during the very extended Squid-3.0 development cycle with lots of major restructuring and destabilization taking place.. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Yes. It's not much use in releaseing a PRE with known major blockers. Well, we all seem to agree on no bugs above a certain level, but differ as to what the maximum rating should be :-) I've been basing my standards on the bugzilla importance labels. PRE requiring: 0 'blocker', 'critical', 'major' judgement call on those labeled 'normal' or lower (few as possible) My PRE list is the one linked from RoadMap under bugzapping. (all bugs minor, either existing in or targeted at a fix 3.1) My RC list extends that to include the 3.0 bugs, so 3.1.RC1 won't go out until there are no big bugs inherited from 3.0. Maybe we should call a bug sprint with PRE1 release. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. Oh boy, I forgot about yet another undocumented stage -- RC! I wonder what PRE stands for then. Pre-RC?! This is just plain wrong. DEVEL releases is rarely needed as the nightly snapshot releases serves this purpose well. Came to light during the very extended Squid-3.0 development cycle with lots of major restructuring and destabilization taking place.. The DEVEL label is not needed indeed, but I was talking about code states. I understand now that you use the PRE state for a different purpose. Please note that your definitions of DEVEL and PRE differ from the ones on the web site. The most annoying thing, IMO, is that the official and your definitions above have two fuzzy lines for DEVEL and PRE states: stability and features. One fuzzy line is tolerable, but two make things really confusing. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Yes. It's not much use in releaseing a PRE with known major blockers. But your definition above says we are still hunting down some bugs. It does not say there are no major bugs left. How about this: Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, Sep 24, 2008 at 4:45 PM, Alex Rousskov [EMAIL PROTECTED] wrote: On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: The DEVEL label is not needed indeed, but I was talking about code states. I understand now that you use the PRE state for a different purpose. Please note that your definitions of DEVEL and PRE differ from the ones on the web site. The most annoying thing, IMO, is that the official and your definitions above have two fuzzy lines for DEVEL and PRE states: stability and features. One fuzzy line is tolerable, but two make things really confusing. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Yes. It's not much use in releaseing a PRE with known major blockers. But your definition above says we are still hunting down some bugs. It does not say there are no major bugs left. How about this: Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. This is a bit like rehashing an old discussion, I'll however give it a shot but not discuss it further. I'm not a particular fan of DEVEL/PRE/RC/STABLE labels. I like your idea about labelling the branching point and keeping timestamps around for the head and post-branching stabilization phase. I don't like much not having a fixed stable marker much tho, what I'd do is: - when major bugs are fixed, a .0 release point is taken. After that during the stabilization phase, milestones are marked with an additional numeral (e.g. 3.2.0.5) - when STABLE level is reached, then a .1 release is taken (3.2.1). After that, it's maintainance mode and new releases are marked by incrementing the third numeral (e.g. 3.2.5). Advantages: - it's fully-numeral - it has a fixed stable marker (the .1 release). - it doesn't change much the current numbering approach My 2c; I won't waste more of anyone's time (re-re-re-re-re-re)resurrecting this discussion. -- /kinkie
Re: [RFC] 3.1 branching
I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. No standard that I know of - timestamps are quite common for prerelease, and some projects also use them for post-release. The closest thing, having been adopted by some other projets, has been Linux's (now abandoned) odd minor releases are devel, even minor releases are stable. -- /kinkie
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: Alex Rousskov wrote: On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. Oh boy, I forgot about yet another undocumented stage -- RC! I wonder what PRE stands for then. Pre-RC?! This is just plain wrong. 'tis documented: http://www.squid-cache.org/Devel/release-process.html Sorry, I should have looked there too. I was talking about http://www.squid-cache.org/Versions/ Although.. from 3.1 - step 1 and 4 are joined, so step 2+ happens parallel to HEAD without locking other new features. and I have not exactly been closely following step7 for 3.0. To pump through the biggest bug fixes faster. I will need a flow chart tool to grok this :-) Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. Suites me either way. Some of the users at AusMeet commented on the confusion of calling a release 3.0.STABLEx when a month later it obviously wasn't. I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. I am not an expert on this, but AFAIK, there are several popular models including odd/even, devel/stable, current/release. Some do release candidates, but it is often just an informal announcement (e.g., snapshot such and such is a release candidate). Many offer VCS access and, hence, can do snapshots (as a convenience for the user). But the main theme seems to be a simple single threshold (if you do not count VCS). The above scheme is pretty much the same as devel/stable approach many projects use. It should be familiar to users and developers alike. The key here is to make it as simple and well defined as possible. I think our scheme is too complex and confusing because we are trying to piggyback too many things onto a version label and make it too fine-grained. This hurts both users and developers. Personally, I have never seen other projects stuffing version numbers with STABLE. It is strange to look at, it is longer to type, and harder to auto-process. IMHO, version should only contain version numbers. Everything else is metadata that does not belong there. I am sure there are projects out there that do similar silly stuff though. Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 17:43 +0200, Kinkie wrote: I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. The closest thing, having been adopted by some other projets, has been Linux's (now abandoned) odd minor releases are devel, even minor releases are stable. See, even Linux managed to abandon an odd naming scheme! We can do it too. :-) BTW, you may notice that we, ourselves, usually use devel/stable terms when talking about releases (ours and others). We rarely tell somebody Oh, just wait for a PRE release or perhaps RC... Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 17:28 +0200, Kinkie wrote: I don't like much not having a fixed stable marker much tho, what I'd do is: - when major bugs are fixed, a .0 release point is taken. After that during the stabilization phase, milestones are marked with an additional numeral (e.g. 3.2.0.5) - when STABLE level is reached, then a .1 release is taken (3.2.1). After that, it's maintainance mode and new releases are marked by incrementing the third numeral (e.g. 3.2.5). Advantages: - it's fully-numeral - it has a fixed stable marker (the .1 release). - it doesn't change much the current numbering approach I like your proposal a lot more than the current scheme, but what is the value of a fixed stable marker? What a fixed marker like that would allow us to do that we cannot do by saying stable or first stable? The only use I can think of is that it would allow us to detect a stable release in a version number that was assigned 5 years ago (e.g., we will know that 3.1.3 was a stable release even 5 years from now). Since that old branch will no longer be supported by then, we should not need that information often. What other uses are there? Thank you, Alex.
Re: [RFC] 3.1 branching
Alex Rousskov wrote: On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: Alex Rousskov wrote: On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. Oh boy, I forgot about yet another undocumented stage -- RC! I wonder what PRE stands for then. Pre-RC?! This is just plain wrong. 'tis documented: http://www.squid-cache.org/Devel/release-process.html Sorry, I should have looked there too. I was talking about http://www.squid-cache.org/Versions/ Although.. from 3.1 - step 1 and 4 are joined, so step 2+ happens parallel to HEAD without locking other new features. and I have not exactly been closely following step7 for 3.0. To pump through the biggest bug fixes faster. I will need a flow chart tool to grok this :-) Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. Suites me either way. Some of the users at AusMeet commented on the confusion of calling a release 3.0.STABLEx when a month later it obviously wasn't. I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. I am not an expert on this, but AFAIK, there are several popular models including odd/even, devel/stable, current/release. Some do release candidates, but it is often just an informal announcement (e.g., snapshot such and such is a release candidate). Many offer VCS access and, hence, can do snapshots (as a convenience for the user). But the main theme seems to be a simple single threshold (if you do not count VCS). The above scheme is pretty much the same as devel/stable approach many projects use. It should be familiar to users and developers alike. The key here is to make it as simple and well defined as possible. I think our scheme is too complex and confusing because we are trying to piggyback too many things onto a version label and make it too fine-grained. This hurts both users and developers. Personally, I have never seen other projects stuffing version numbers with STABLE. It is strange to look at, it is longer to type, and harder to auto-process. IMHO, version should only contain version numbers. Everything else is metadata that does not belong there. I am sure there are projects out there that do similar silly stuff though. Just brain dumping at 4am, but, how about this: stuff goes into HEAD (3-) ... after a period we branch (3.1) with features from HEAD ... fix all known bugs and release 3.1.0-rc1 ... if confirmed stable gets officially released as 3.1.1 ... any critical bug found, or large accumulation of minor ones causes 3.1.2 etc ... work continues on HEAD for next branching point of (3.2). Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 05:00 +1200, Amos Jeffries wrote: Just brain dumping at 4am, but, how about this: stuff goes into HEAD (3-) ... after a period we branch (3.1) with features from HEAD ... fix all known bugs and release 3.1.0-rc1 ... if confirmed stable gets officially released as 3.1.1 ... any critical bug found, or large accumulation of minor ones causes 3.1.2 etc ... work continues on HEAD for next branching point of (3.2). This is much better than the current scheme and is similar to what Kinkie proposed. The three schemes differ in when pre-stable releases of a branch are made and how they are numbered: Alex (release development versions early and until no bugs left; keep metadata elsewhere): 3.1.0, 3.1.1, 3.1.2, ... 3.1.27, 3.1.28, ... Kinkie (release development versions early and until no bugs left; x.y.0.z means devel or beta; x.y.1 and later are stable): 3.1.0.0, 3.1.0.1, 3.1.0.2, ... 3.1.1, 3.1.2, ... Amos: (use BZR snapshots for development, release first numbered version when all bugs are fixed; x.y.0-rcZ means release candidate): ... 3.1.0-rc1, 3.1.0-rc2, 3.1.0-rc3, ... 3.1.1, 3.1.2, ... Is this summary correct? Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 21:26 +0200, Kinkie wrote: It's only a psychological thing. .0 sounds prerelease. Also the fact that devel will not bump the patchlevel release feels like slowing down and checking things out for the first number, 1. Understood, thank you. None of this has (or should have) any effect on the actual development cycle, it's just conventions. Right. If we were machines, only the rules for branching and releasing would matter. Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote: On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. Numeric numbering with 0 as beta is used by many packaging schemes, and would not confuse anyone. I am positive on getting rid of the labels and use the scheme proposed by Kinkie. Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. To answer Alex regarding the RC (Release Candidate) this is not a release tag in itself. It's more of a temporary flag. It has also used between STABLE releases if there has been large or packaging changes, and those releases is not announced outside squid-dev or visible on the web site. Sounds good. Thank you, Alex.
Re: [RFC] 3.1 branching
On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 01:21 +0200, Henrik Nordstrom wrote: On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. good stuff snipped So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 +1 Alex.
Re: [RFC] 3.1 branching
On ons, 2008-09-24 at 21:26 +0200, Kinkie wrote: The version X.Y.Z for all Z W approach means that it's not easy to tell what the state of a release is without knowing what W is for each X,Y. Even then you don't know as the notion of something being stable is very temporal in nature and often gets revoked as bugs is found. None of this has (or should have) any effect on the actual development cycle, it's just conventions. Correct. Only the rules around when branching or merges to trunk may take place has significant impact on development cycle. And I think we are all leaning towards a more open approach there based on branch early without blocking trunk. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote: On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. Numeric numbering with 0 as beta is used by many packaging schemes, and would not confuse anyone. I am positive on getting rid of the labels and use the scheme proposed by Kinkie. Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Well, They way I'm thinking of the numbers your sequence is 1-off. We are not stopping the daily snapshots, I think. So your 4-th place digit is the same as the snapshot date. We have NO new features added after X.Y.0, NO non-bug changes at all. Stability seems to be taking the same length of time as a new Y release. Which means we end up with 3.1.1, 3.2.1, 3.3.1 with possibly many smaller 4-place releases for each day or bugfix patch. 3-levels should be sufficient. It's also not a major change from current practice, only dropping the name 'STABLE' from packages. We don't really need the RC flag-days in my scheme either. I just thought it would be slightly more descriptive for people to understand the .0 code in those bundles is still not proven trustworthy for production. Also leaves the option if a major bug fix went in (rare) we could -rc a few test bundles before declaring it fixed). If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. To answer Alex regarding the RC (Release Candidate) this is not a release tag in itself. It's more of a temporary flag. It has also used between STABLE releases if there has been large or packaging changes, and those releases is not announced outside squid-dev or visible on the web site. Sounds good. Thank you, Alex.
Re: [RFC] 3.1 branching
On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Amos
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Amos, I am sorry, but I honestly do not understand this and the previous your sequence is 1-off email. Perhaps the dancing Xs, Ys, and Zs with some implied meaning confuse me. It feels like there is some basic misunderstanding, especially since yours and Kinkie's earlier suggestions were very similar (or so I thought!). Could you please restate your proposal in a concise step-by-step form, as opposed to explaining why the above plan would not work? This may put us back on the same page again. Thank you, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Amos, I am sorry, but I honestly do not understand this and the previous your sequence is 1-off email. Perhaps the dancing Xs, Ys, and Zs with some implied meaning confuse me. It feels like there is some basic misunderstanding, especially since yours and Kinkie's earlier suggestions were very similar (or so I thought!). They are, very similar. I just don't see any need for 4-numbers in Kinkies Scheme. Could you please restate your proposal in a concise step-by-step form, as opposed to explaining why the above plan would not work? This may put us back on the same page again. Okay, using actual numbers and timelines of 3.1/3.2 to make it clearer than the abstract. Dates are mostly fictional but based on reasonable guesses. trunk (3.1.0) - sept 30: branch with 10 new features release 3.1.0 (makes trunk now 3.2.0) - oct 30: everything found 'stable' release 3.1.1 - nov 30: 10 new major+ bugs fixed :-( release 3.1.2 (move 3.1.1 down to obsolete list) - dec 30: 2 new major+ bugs found release 3.1.3 - jan 1 : branch with 9 new features release 3.2.0 (makes trunk now 3.3.0) - feb 1: everything found 'stable' release 3.2.1 release 3.1.4 final bug fixes. - ... trunk continues its merry way getting new features the whole time as 3.*.0 without any flag points. grok? Nothing implies a guaranteed STABLE. Merely the highest number (ie 3.1.4) is most bug-free for all fixable problems of 3.1
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote: trunk (3.1.0) - sept 30: branch with 10 new features release 3.1.0 (makes trunk now 3.2.0) - oct 30: everything found 'stable' release 3.1.1 - nov 30: 10 new major+ bugs fixed :-( release 3.1.2 (move 3.1.1 down to obsolete list) - dec 30: 2 new major+ bugs found release 3.1.3 - jan 1 : branch with 9 new features release 3.2.0 (makes trunk now 3.3.0) - feb 1: everything found 'stable' release 3.2.1 release 3.1.4 final bug fixes. - ... trunk continues its merry way getting new features the whole time as 3.*.0 without any flag points. So how do we tell users to try something between 3.1.0 and 3.1.1? Refer to some specific daily snapshot? Kinkie+ scheme would use numbered beta releases: 3.1.0.1, 3.1.0.2, etc. I think numbered releases are better than daily snapshots for asking users to try something: Argh! Somebody committed a bug 5 minutes before the snapshot we thought we would recommend to the user. Let's wait another day and hope that it does not happen again. People! Please do not commit anything because we need a clean daily snapshot!. (makes trunk now 3.2.0) (makes trunk now 3.3.0) I am not sure what those mean. Trunk is a trunk. 3.2.0 is the first release on a 3.2 branch, right? I am ignoring those for now. We may reach 3.1.6 if things go badly, or if new features get developed really slowly. But I don't think we will get enough checkpoints in the devel cycle to warrant two layers of .0.1 - .6.2 The extra development release layer in Kinkie+ scheme is only used for 3.1.0, never for 3.1.6 or other non-zero releases. People seem happy with the release approach and timelines, just not the current bad naming scheme which implies releases are guaranteed STABLE when in fact only a bug fix improvement. Well, there are several problems with the current scheme, but I think we should preserve the notion of a stable state of the branch. It is not a guarantee, but it allows users to select the right branch/version to deploy. In Kinkie+ scheme and in your scheme, the branch is considered stable when 3.1.1 is released. Before that, there are big known bugs. After that, there should not be any and those that appear should get higher fixing priority. The only significant difference I see is that you want folks to use daily snapshots during development stage of the branch and Kinkie wants sub-numbered releases. Thank you, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote: trunk (3.1.0) - sept 30: branch with 10 new features release 3.1.0 (makes trunk now 3.2.0) - oct 30: everything found 'stable' release 3.1.1 - nov 30: 10 new major+ bugs fixed :-( release 3.1.2 (move 3.1.1 down to obsolete list) - dec 30: 2 new major+ bugs found release 3.1.3 - jan 1 : branch with 9 new features release 3.2.0 (makes trunk now 3.3.0) - feb 1: everything found 'stable' release 3.2.1 release 3.1.4 final bug fixes. - ... trunk continues its merry way getting new features the whole time as 3.*.0 without any flag points. So how do we tell users to try something between 3.1.0 and 3.1.1? Refer to some specific daily snapshot? Kinkie+ scheme would use numbered beta releases: 3.1.0.1, 3.1.0.2, etc. I think numbered releases are better than daily snapshots for asking users to try something: Argh! Somebody committed a bug 5 minutes before the snapshot we thought we would recommend to the user. Let's wait another day and hope that it does not happen again. People! Please do not commit anything because we need a clean daily snapshot!. Thats all in trunk. We are talking numbering systems for the branches. To which the only commiter should be the branch maintainer. We can make a new clean snapshot at any point if its really warranted, even to the point of calling it a 3.1.0.1 'release' 3 times in one day. That said, maintainers can do the same for trunk too if convinced its worth the trouble. (makes trunk now 3.2.0) (makes trunk now 3.3.0) I am not sure what those mean. Trunk is a trunk. 3.2.0 is the first release on a 3.2 branch, right? I am ignoring those for now. We may reach 3.1.6 if things go badly, or if new features get developed really slowly. But I don't think we will get enough checkpoints in the devel cycle to warrant two layers of .0.1 - .6.2 The extra development release layer in Kinkie+ scheme is only used for 3.1.0, never for 3.1.6 or other non-zero releases. This is a contradiction of your earlier how do we tell users to try something between 3.1.0 and 3.1.1? The 'please try X' request is done as often after 3.1.1 as before. We come back to the problem of until squid is 100% major bug free for all users (now and in future) it never actually qualifies for that 3.1.1 rating. Under my scheme, we would not grant such development test points a full version number, they can get a rc1, rc2, etc (or as at present a '20080912') if needed. People seem happy with the release approach and timelines, just not the current bad naming scheme which implies releases are guaranteed STABLE when in fact only a bug fix improvement. Well, there are several problems with the current scheme, but I think we should preserve the notion of a stable state of the branch. It is not a guarantee, but it allows users to select the right branch/version to deploy. In Kinkie+ scheme and in your scheme, the branch is considered stable when 3.1.1 is released. Before that, there are big known bugs. After that, there should not be any and those that appear should get higher fixing priority. The only significant difference I see is that you want folks to use daily snapshots during development stage of the branch and Kinkie wants sub-numbered releases. Yes, pretty much. If you look at the changeset pages for each 3.0 release so far, there are fixes for some very major bugs in there as far as 3.0.STABLE7. If we had run a whole cycle of 3.0.0.N (aka 4 years of testing PRE1 - RC2), we would have still probably have released 3.0.1 (aka 3.0.STABLE1) with those bugs in. Or maybe gone straight from 3.0.0.16 to 3.1.0.1 this month I don't realistically expect 3.1 to be perfect either. I'd rather have fixed point releases (3.0.1) based on some known workable code, and a pile of sequentially tagged bundles of 'maybe dodgy code' on top for new un-tested bug fixes. Amos
Re: [RFC] 3.1 branching
Lets set a date: 29 September? Well, I'll call for a partial hold right now. Please only commit bug fixes, minor cleanups, and features already on the roadmap for 3.1. The rest can be queued for commit post branch. 5 days to go and these bits left * connection pinning I thinking it's been outstanding long enough we should get it into 3.1, even if we have to hold PRE1 a week after the branch to stabilize it (or test it in PRE1 ?). Awaiting merge. (1-2 days). * kerberos helper Markus has supplied another set of code, I assume its been tested externally and just needs a drop-in. Awaiting re-submission with some alterations. Non-blocker. * eCAP Awaiting merge submission. * source layout Started. Non-blocker. * source formatting scripts committed for use already, I was planning on starting the re-format and testbed run today here. Now waiting on completion of other feature code. Other misc stuff which qualifies but need some work if people have time: Awaiting a verify: http://www.squid-cache.org/bugs/show_bug.cgi?id=2433 Awaiting a verify test and debug: http://www.squid-cache.org/bugs/show_bug.cgi?id=2393 Awaiting a developer: * testbed level-02-maximus.opts opposite of minimal. Everything enabled, leave configure to handle clashes properly etc. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote: Lets set a date: 29 September? Well, I'll call for a partial hold right now. Please only commit bug fixes, minor cleanups, and features already on the roadmap for 3.1. The rest can be queued for commit post branch. 5 days to go and these bits left * connection pinning I thinking it's been outstanding long enough we should get it into 3.1, even if we have to hold PRE1 a week after the branch to stabilize it (or test it in PRE1 ?). Awaiting merge. (1-2 days). Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk code is stable enough to be called PRE at this point, so I was expecting DEVEL. Personally, I would just call it 3.1.0 and categorize it as development on the web site until we can move it into the stable category (after a few 3.1.x releases). * kerberos helper Markus has supplied another set of code, I assume its been tested externally and just needs a drop-in. Awaiting re-submission with some alterations. Non-blocker. * eCAP Awaiting merge submission. * source layout Started. Non-blocker. * source formatting scripts committed for use already, I was planning on starting the re-format and testbed run today here. Now waiting on completion of other feature code. Other misc stuff which qualifies but need some work if people have time: Awaiting a verify: http://www.squid-cache.org/bugs/show_bug.cgi?id=2433 Awaiting a verify test and debug: http://www.squid-cache.org/bugs/show_bug.cgi?id=2393 Awaiting a developer: * testbed level-02-maximus.opts opposite of minimal. Everything enabled, leave configure to handle clashes properly etc. Other important problems: http://www.squid-cache.org/bugs/show_bug.cgi?id=2459 http://www.squid-cache.org/bugs/show_bug.cgi?id=2460 I have asked somebody to work on these for the next 10 days, but I do not know if they will be able to fix them. I can work on them after eCAP. Also, it would be nice to review and commit TCP_RESET propagation patch: http://www.squid-cache.org/bugs/show_bug.cgi?id=2042 Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote: Lets set a date: 29 September? Well, I'll call for a partial hold right now. Please only commit bug fixes, minor cleanups, and features already on the roadmap for 3.1. The rest can be queued for commit post branch. 5 days to go and these bits left * connection pinning I thinking it's been outstanding long enough we should get it into 3.1, even if we have to hold PRE1 a week after the branch to stabilize it (or test it in PRE1 ?). Awaiting merge. (1-2 days). Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk code is stable enough to be called PRE at this point, so I was expecting DEVEL. Personally, I would just call it 3.1.0 and categorize it as development on the web site until we can move it into the stable category (after a few 3.1.x releases). i ws * kerberos helper Markus has supplied another set of code, I assume its been tested externally and just needs a drop-in. Awaiting re-submission with some alterations. Non-blocker. * eCAP Awaiting merge submission. * source layout Started. Non-blocker. * source formatting scripts committed for use already, I was planning on starting the re-format and testbed run today here. Now waiting on completion of other feature code. Other misc stuff which qualifies but need some work if people have time: Awaiting a verify: http://www.squid-cache.org/bugs/show_bug.cgi?id=2433 Awaiting a verify test and debug: http://www.squid-cache.org/bugs/show_bug.cgi?id=2393 Awaiting a developer: * testbed level-02-maximus.opts opposite of minimal. Everything enabled, leave configure to handle clashes properly etc. Other important problems: http://www.squid-cache.org/bugs/show_bug.cgi?id=2459 http://www.squid-cache.org/bugs/show_bug.cgi?id=2460 I have asked somebody to work on these for the next 10 days, but I do not know if they will be able to fix them. I can work on them after eCAP. Also, it would be nice to review and commit TCP_RESET propagation patch: http://www.squid-cache.org/bugs/show_bug.cgi?id=2042 Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 02:16 +1200, Amos Jeffries wrote: Lets set a date: 29 September? Well, I'll call for a partial hold right now. Please only commit bug fixes, minor cleanups, and features already on the roadmap for 3.1. The rest can be queued for commit post branch. 5 days to go and these bits left * connection pinning I thinking it's been outstanding long enough we should get it into 3.1, even if we have to hold PRE1 a week after the branch to stabilize it (or test it in PRE1 ?). Awaiting merge. (1-2 days). Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk code is stable enough to be called PRE at this point, so I was expecting DEVEL. Personally, I would just call it 3.1.0 and categorize it as development on the web site until we can move it into the stable category (after a few 3.1.x releases). Before conn-pinning came up as an option I was thinking PRE. But it and the other things destabilize enough to warrant a DEVEL period at least. I'll decide after branching whether to release DEVEL, immediately or wait. Concentration on the branch blockers then we can split and put the new stuff and enhancements in trunk away from the hardening 3.1.x. * kerberos helper Markus has supplied another set of code, I assume its been tested externally and just needs a drop-in. Awaiting re-submission with some alterations. Non-blocker. * eCAP Awaiting merge submission. * source layout Started. Non-blocker. * source formatting scripts committed for use already, I was planning on starting the re-format and testbed run today here. Now waiting on completion of other feature code. Other misc stuff which qualifies but need some work if people have time: Awaiting a verify: http://www.squid-cache.org/bugs/show_bug.cgi?id=2433 Awaiting a verify test and debug: http://www.squid-cache.org/bugs/show_bug.cgi?id=2393 Awaiting a developer: * testbed level-02-maximus.opts opposite of minimal. Everything enabled, leave configure to handle clashes properly etc. Doing right now. Other important problems: http://www.squid-cache.org/bugs/show_bug.cgi?id=2459 http://www.squid-cache.org/bugs/show_bug.cgi?id=2460 I have asked somebody to work on these for the next 10 days, but I do not know if they will be able to fix them. I can work on them after eCAP. If they need a mentor I can probably assist in auditing 2459. Also, it would be nice to review and commit TCP_RESET propagation patch: http://www.squid-cache.org/bugs/show_bug.cgi?id=2042 Well, this is what the branch is for, so we can commit these 'nice' things to trunk for 3.2 from 30Sept on and start their testing as well without affecting the stability of 3.1. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Amos
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 14:34 +1200, Amos Jeffries wrote: Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk code is stable enough to be called PRE at this point, so I was expecting DEVEL. Personally, I would just call it 3.1.0 and categorize it as development on the web site until we can move it into the stable category (after a few 3.1.x releases). Before conn-pinning came up as an option I was thinking PRE. But it and the other things destabilize enough to warrant a DEVEL period at least. I'll decide after branching whether to release DEVEL, immediately or wait. Please email RFCs before making the final decision about the labels and releases. Until we get to a stable stage, the labeling and timing of the releases should be discussed as it can benefit from what others have seen in their tests. For example, IMO, the trunk was/is not PRE-ready even after the recent fixes and before conn-pinning. In general, I think we should virtually always do at least one development release before a PRE. Jumping from trunk to PRE is much more likely to discredit the branch than a development-to-PRE delay. PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) Concentration on the branch blockers then we can split and put the new stuff and enhancements in trunk away from the hardening 3.1.x. Other important problems: http://www.squid-cache.org/bugs/show_bug.cgi?id=2459 http://www.squid-cache.org/bugs/show_bug.cgi?id=2460 I have asked somebody to work on these for the next 10 days, but I do not know if they will be able to fix them. I can work on them after eCAP. If they need a mentor I can probably assist in auditing 2459. Thank you, I will keep that in mind! Also, it would be nice to review and commit TCP_RESET propagation patch: http://www.squid-cache.org/bugs/show_bug.cgi?id=2042 Well, this is what the branch is for, so we can commit these 'nice' things to trunk for 3.2 from 30Sept on and start their testing as well without affecting the stability of 3.1. I meant that it would be nice to include RESET propagation in v3.1 not v3.2 :-). Not a big deal though. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Thank you, Alex.
