On 10/22/05, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote: > Here are some humble suggestions from our experience: > > > 1) Split the release schedules for the different parts > > myfaces-api, myfaces-impl, and indeed, myfaces-shared, and tomahawk, > need to be on different release tracks, and have different version > numbers. You are now in a situation that one release is waiting for the > other, almost in deadlock. This poses no difficulties for developers. > This makes it easier for developers. This also makes it easy to make > different contributors responsible for the releases and other issues of > the different parts, distributing the work and responsibility.
+1 > 2) Drop the combined package > > This again makes releases harder, and there is no need for that. > Tomahawk is a separate product anyway: it also works (or should work in > the near future) with other JSF implementations. Developers will > appreciate the clarity. +1 (customers will also appreciate this) > 3) Automate the release procedure; use maven > > Yes, I know this was discussed 3 months ago. But it is clear that the > release procedure is manual now, that there are problems automating it. > With maven, most of the work is done already, and you will be able to > spend the time you spend now on duplicating maven functionality in ant, > to automate the missing parts, like running the JSF compatibility > tests. +1 (use Maven2) > 4) Don't be afraid of a new release. > > E.g., take 1.1.0. This release is obviously broken, and there are over > 80 fixes in the repo since then already. But, no release. _Each_ of > those 80 fixes warranted a new release. _Each_ of those releases would > have helped a number of people that were fighting a bug in 1.1.0. > > If this means that there is a new release every day, in the extreme, > that's ok. If the release procedure is automatic, that doesn't take any > effort, and it is feasible for developers to track progress (is my bug > fixed in this release or not). Now, everybody in development is working > with nightlies, which introduces terrible uncertainty which is almost > impossible to defend to project managers or clients. > And it doesn't stay that way. In the first days after 1.1.0, it would > have meant a daily bugfix release, yes. After a week, it would go down > to a release every 3 days, and by now, we would probably have 1.1.21. > That's ok. Developers _can_ count past 10. > > If this goes to far for you, for bugfix releases (kudos for the > separate 1.1 branch), reverse the issue: in the first weeks, set a > release schedule: a new release every friday 00:00h. The fixes that are > in the branch make the release, the rest is for next week. If there are > blocking issues at that time, branch the branch, and fix them asap. > Again, this stabilizes after a while, when there simply are no new > commits in the branch since last friday. I promise it does! > > Developers see the trend in the release schedule. After a while, the > curve flattens, and we all know that we reached a certain stability. We > don't want to use a .0 version in deployment; we know there are bugs in > .0 versions of _every_ product. If we have a feeling about the release > schedule, we will use earlier versions, if our deadline is far enough > in the future, so you will have testers. +1 If trains leave often enough, missing the train is not a big deal. Trains will also arrive more frequently. :-) > 5) Forget the RC-approach. > > For one, given the experience of the last few weeks, this approach > obviously isn't > working. Just depend on the stabilising nature of frequent, consecutive > bugfix releases. You will have more testers this way than with the > RC's which are impossible to find (e.g., no maven repo release). I know > of nobody in production that will go through the effort of working with > an RC. +0.5 :-) RC makes sense for dot-zero release, like 1.0, 2.0 and maybe for a dot-N release like 1.1, 2.1, etc, but not for bugfix releases. Subsequent bugfix releases definitely do not require an RC, but they do require thorough (automated) testing. Kind Regards, John Fallows.
