What about using a "release candidate branch" in place of a "release branch" ?
With this I mean: 1) the release candidate branch could be started at any time (even from the trunk as it is right now) 2) the actually open JIRAs should be selected and the "fix version" field should be changed to the new scheduled release candidate for what the community agrees to be included in the release (even some new features). This gives a clear idea to all the community of what needs to be done to get the release done. And I guess all the active community will try to have them done with a high priority. (The answer to the question "When will we have the new release?" will be "When we will have all the scheduled issues closed. Please give them a look and attach a (tested) patch." 3) when all the JIRAs scheduled on the release candidate are closed the release can be done, a tag is created and the release (maintenance) branch is started where only bug fix are committed. 4) in addition to this I would create a tag from the release maintenance branch whenever a reasonable amount of fixes are done. I think this approach is very standard, no extra efforts are requested that we cannot do and gives a clear idea to everybody of where we are. -Bruno 2008/11/14 David E Jones <[EMAIL PROTECTED]> > > On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote: > > David E Jones wrote: >> >>> I don't mean to dilute the framework release effort. But at the same >>>> time, it seems to me issues are coming up in R4 that have been addressed in >>>> the trunk. >>>> >>> While to some extent this depends on the type of issue, in general issues >>> in the 4.0.0 branch should be fixed in that branch by the "sub-community" >>> that has formed around the branch. If things are not getting fixed, to me >>> that means the branch has not attracted enough of a user and contributor >>> community. I don't know how to fix that problem... >>> >> >> It is true that most of the bugs discovered in R4 are fixed as they come >> up. I was thinking more along the line of the kinds of things that were >> corrected by refactorings and such. >> >> I've run across a number of people using R4 and service providers who are >> using R4 for their customer's deployments. In addition, Opentaps is based on >> R4. So, there is a sizeable R4 community out there, even if they aren't >> vocal on the mailing lists and such. >> >> I guess the goal or purpose of a Release 5 would be the same as Release 4 >> - to provide the opportunity to build on a target that isn't moving. >> >> I agree that there needs to be a community of people who want it and are >> willing to support it. I was just tossing the idea out there, but at this >> point in time there doesn't seem to be much interest. >> > > These are good points Adrian. Don't let my "Devil's Advocate" approach > scare you away or make you think there is no interest in doing these. I > imagine there are many people who would like to see release branches happen. > > Part of the reason I wrote some doubts about it is that there is an open > source mantra of "release early, release often" and I was wondering about > that... What if we took the opposite approach of "never release"? It's the > total opposite extreme and I'm not completely sure I like the idea, but it > has some really interesting points. For example it encourages: > > 1. community interaction, even for those who are just "users" and not > sending things back > 2. frequent upgrades by all users to resolve issues > 3. community responsibility, rising the priority of things like automated > testing, and giving people more reasons to get involved with that testing > and contribute tests > 4. base application design decision refinement to help people with regular > updates and resolving issues while not creating new ones > 5. something the press can write about that is very different from things > done in other places > 6. a social experiment in collaborative enterprise software that is yet > unseen in the world > > Of course, there are disadvantages, like: > > 1. a smaller user community because the prospect is scary > > Maybe that's it. I really think that if as a community we work more on > automated regression tests and such we'll have a higher quality of software > in the trunk than is in the release branches, partially because of what > Adrian mentioned (and I alluded to) where certain types of issues require a > lot of refactoring and aren't simple fixes that can go into a release > branch. > > Anyway, something to think about. In a way doing release branches breaks > important aspects of the "never release" approach because things like #1, #2 > and certain of the others won't happen, or won't happen as much. Actually, > it applies to more, maybe especially #3. If we never release, developers > have no excuse of making things unstable, or committing without thinking > about things, or throwing stuff out for they are designed well. There is no > excuse of "if people want something stable, use the release branch, and > leave us alone!" > > I'm still for doing another release branch early next year (and continuing > with 18-24 months between branches), unless a lot of people find the "never > release" philosophy interesting. > > -David > > >
