NOTE: Quality/Code Tidy/etc. discussion moved to 'Beehive "Quality Processes"' thread.
RE #2: The pitch I made is less complex than what you're suggesting. I can see the reasons why we need to go with an extra layer of branches to both support old releases and forge ahead on new ones. Let me take a crack at redrawing the picture in the diagram. I will put more words around branching vs. labeling too. RE #3: I like this approach. Rotan? Others? > -----Original Message----- > From: Ken Tam > Sent: Tuesday, October 12, 2004 2:59 PM > To: Beehive Developers > Subject: RE: [proposal] Beehive release strategy > > Overall strategy looks good. Thanks Heather! > > Drilling in: << snip >> > 2) Can the doc be explicit about using actual subversion concepts of > branches and tags? This would be super helpful in avoiding confusion > over what's really going on. For example: > a) branch for work on major (X.) releases. > b) tag revisions within a branch for the .y.z revisions, including > ".0.0". > > This implies that "minor" and "fixpack" releases are developed on the > same branch. Depending on the scope of changes going on for "minor" > releases, we might consider adding: > c) branch within a major release branch for work on fixpack releases > against released minor versions. > > It would be simpler to say "fixpacks only come out in the context of the > current minor version", but that might be too restrictive. Thoughts? > Consider the following version number sequence: > > 1.0.0 > 1.0.1 > 1.1.0 > > now, do we permit a 1.0.2? Or do we say that if you want a change to > 1.0.1, you'll have to get it in 1.1.1? > In the former case, we're saying that we want to allow provision (c), > and 1.0.2 is made in a branch-of-a-branch while 1.y.z work continues on > a branch. > > 3) To speak to Rotan's point about an "unambiguous time to cut a > fixpack", how about leaving it up to the community? If enough people > feel that enough fixes have gone in to make it desirable to have a > formal tag/release number tracking that collection, then they can > propose a fixpack. > > > -----Original Message----- > From: Heather Stephens > Sent: Tuesday, October 05, 2004 4:23 PM > To: Beehive Developers > Subject: RE: [proposal] Beehive release strategy > > Thanks for the input Rotan. > > My thoughts on some of your items below. > > Are Rotan and I really the only ones with opinions? It would > be great to hear others' input too. *hint, hint* > > >> 3: If I have version X.y.z, will there be an easy way for me to > >> determine the feature set? > > Yes. Good point. I think we have to have that. I'd like to > writeup a document for our feature planning process that > would include both how somebody could put a feature on the > docket, how we target them to specific releases and how we > indicate to each other that a given feature is complete and > ready to be used. Obviously using Jira for much of this > would really help. :) > > >> 4: 'When appropriate, cut a "fix pack"...' needs clarification. > >> Will there be a set of unambiguous criteria against which one can > >> ascertain whether or not the time is 'appropriate' to cut? << snip >> > > -----Original Message----- > From: Rotan Hanrahan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 21, 2004 5:21 PM > To: [email protected] > Subject: FW: [proposal] Beehive release strategy > > I'm sure the Dev team would be happy to contribute additional > comments on the proposed Beehive release strategy, so as > requested I'm sending "this" to "there". > ---Rotan > > -----Original Message----- > From: Heather Stephens [mailto:[EMAIL PROTECTED] > Sent: Tue 21/09/2004 22:16 > To: Rotan Hanrahan; [EMAIL PROTECTED] > Cc: > Subject: RE: [proposal] Beehive release strategy > > > > Hey Rotan- > > This is all great feedback and seem like good > discussion items and > questions for the team. It doesn't seem like there is anything > particularly private or sensitive in this email and so > I think it would > be great if we could have this discussion in a more > public forum on > beehive-dev. Would you mind sending this there to open > it up to the > larger community? > > H. > > -----Original Message----- > From: Rotan Hanrahan [mailto:[EMAIL PROTECTED] > Sent: Friday, September 17, 2004 9:52 AM > To: [EMAIL PROTECTED] > Subject: RE: [proposal] Beehive release strategy > > Quick feedback: > > 0: Looks good. > > 1: Is there any way to validate that a successful unit > test sequence was > executed? > > In effect, I'm wondering if there's a way to prevent check-in > *unless* > the tests have passed. > > 2: Is there a code tidy process? > > This is a sweeper task that one or more people do. Look > at code and tidy > the comments or layout according to style rules we > agree in advance. > Ambiguous comments get referred to the author for clarification. > This > might sound like a minor task, but if we have a large > community and not > all are native speakers of the comment language (ie > english) then > someone has to make sure it is clear and makes sense. > Preferably good > coders with good communication skills. It also provides > an avenue for > contributions that may not be code mods, but would > still be very useful > to those who do the actual coding. > > 3: If I have version X.y.z, will there be an easy way for me to > determine the feature set? > > 4: 'When appropriate, cut a "fix pack"...' needs clarification. > > Will there be a set of unambiguous criteria against > which one can > ascertain whether or not the time is 'appropriate' to cut? > > 5: We need a stable objective quality assessment > mechanism from which we > can observe trends. > > For example, we could agree a hardware and o.s. > reference environment, > and then run an agreed set of tests on this platform, > measurings key > statistics as we go. Over time we will obtain some > objective performance > quality trends. We might then be able to sync a > feature/bug introduction > to a change in performance (+/-), which in turn would suggest an > inspection of that code (to fix or to learn). > > > Regards, > ---Rotan. > > > -----Original Message----- > From: Heather Stephens [mailto:[EMAIL PROTECTED] > Sent: 14 September 2004 00:22 > To: [EMAIL PROTECTED] > Subject: FW: [proposal] Beehive release strategy > > > FYI. Feedback appreciated. > > -----Original Message----- > From: Heather Stephens > Sent: Monday, September 13, 2004 4:20 PM > To: Beehive Developers > Subject: [proposal] Beehive release strategy > > Hi all- > > I've been putting some thought into a release strategy > we might use for > Beehive. http://wiki.apache.org/beehive/Release_20Process > > Please take some time to review and assess it as the > Beehive general > release model. If you would raise any concerns or suggest > revisements/refinements on this alias for further > discussion that would > be fabulous. > > Timeline goal: > 9/19/04: Close on discussion and resolve any issues > 9/20/04: Finalize proposal and send to a vote at the PPMC > > Cheers. > Heather Stephens > > > > > > >
