David, I have read the "Release Plan" but it is hard for me to find a match to what I see on the SVN. In particular I do not see those key policies actuated:
- An initial pre-built package will be created and made available to help get people started with the branch - Once a release branch stabilizes an initial "stable" release tag and pre-built package will be issued Where are "pre-built packages" ? I am sorry but I must say that the "Release Plan" seems to me 1) not actuated and 2) not as standard as a "release candidate" would be. My two cents, - Bruno 2008/11/15 David E Jones <[EMAIL PROTECTED]> > > Check out the "Release Plan" document on docs.ofbiz.org... > > -David > > > > On Nov 15, 2008, at 1:58 AM, Bruno Busco wrote: > > 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 >>> >>> >>> >>> >
