> Ok, so maybe this is the thread for these comments I have sitting on > for some time. > _Please_ don't be offended, we _do_ appreciate the work and the results > of the MyFaces contributors and the whole community. > > But you definitely have a release problem. > > 3 anecdotal examples: the ages it took from 1.0.9 to a next release, > the problems introduced from a stable nightly to 1.1.0, and the ages it > is taking to release 1.1.1 to replace the broken 1.1.0 (a "quick" > bugfix release was planned over a month ago).
A month is quick in Open Source development. We all have day jobs and we are spread out in several time zones. Each release must also pass the TCK which takes time. > We now have 3 products deployed using MyFaces, and each is deployed > using a nightly. And we are definitely not alone in this. We > communicate to our clients at this time that official MyFaces releases > should be avoided! Most nightlies are more stable. There is one important bug in the 1.1.1 release but there is an easy workaround. Other then that the release is very stable IMO. There are still lots of bugs being discovered and fixed and so depending on your issues, the nightly might be a better fit for you. But those fixes and changes can introduce new problems so I would disagree that the nightlies are more stable. At any point there could be serious new issues introduced in a nightly. But that's your call. You can do what you want and tell your clients whatever you want. > > 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. Are you crazy? How would this simplify things? We have enough trouble getting the combined release done. Its more then just executing a simple build script. > > > 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. I tend to agree with this one but others feel strongly about having the combined package. I don't see how this affects you if you don't want to use it. It doesn't really slow us down other then its one more jar that has to be tested, etc. Now that the sandbox is out of the myfaces-all.jar the process is simpler. > > > 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. Maven won't make it any easier then Ant. I don't think anyone can convince me of that. Maven might help slightly with the website publication and a few other things but we have very good Ant scripts that took a long time to write. At some point we can consider Maven but that will just delay the next release you are constantly looking for. Maven will be an investment that will take quite a bit of time and testing. As Martin said, automating the TCK is not really feasible. Believe me, we've automated most of what we can. Its just more complicated then you might realize. > > > 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. Sorry but a major -1 for this. I understand your frustration at the pace of the releases but nightly or weekly releases would be insane. I don't know of a single ASF project that does this. Ask yourself why this is the case? Is it because nobody has ever thought of this idea? Clearly not. It seems that other projects have rejected this on the same grounds that I have. All of your effort goes into builds and releases and nobody is using the same version anymore. There is a nightly build so in theory we are already releasing every night. What more do you need? > > > 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. Again -1. I don't like the RC either but people seem to hold off on using the nightlies and doing serious testing until we approach release time. If you give them an official RC they will test it because that is basically "last call" before the release. We're not going to do Maven repository releases for RC and if that's what you need to test a RC then you are out of luck. Most of us can test just fine without Maven. If you need Maven just create your own local library. The branch and RC process should increase stability of the builds. I think we are on the right track here. [snip] sean
