So, I am pretty much of the same opinion as Dave. I think it would help us out a lot with our work on BSC if Roller was kept in sync, however I understand that in many ways it may not be best to force Roller into a monthly release cycle.
I would also like to add that nothing is set in stone, so if on a given month it just isn't going to work to do a Roller release, then fine, we don't do it. However, as an example, our latest code on BSC is the current trunk and we feel that this easily could have been a Roller 1.3 release. It includes the new theme management code, the pojo wrappers, and some bug fixes. It's been running very well for us and I believe it certainly includes enough new features to warrant an actual release, plus the upgrade process is nothing, just deploy the new code and you're done. One of the proposed plans to make sure new releases are stable and easy to upgrade is to only allow schema changes for major releases (i.e. 1.x to 2.x). We would then enforce the rule that any minor release does not contain actual schema changes and therefore the upgrade path for minor releases can be kept to an absolute minimum. Under this plan we would schedule major releases roughly every 3 months or so, meaning that we would typically release a new major version like 2.0 and do 2-3 minor releases off that version before doing a new major release. Of course we would also maintain each major version in it's own branch and we would commit bug fixes to old branches if needed, however the expectation for Roller customers/users is that to get the latest features you have to be on the latest major version. So given our current situation I am suggesting this ... - we continue to do 1.x releases off the trunk each month - when 2.0 is ready the trunk gets branched into the 1.x branch and 2.0 goes to trunk - after the first 2.0 release we create a 3.x branch where anyone can work on code that requires a schema change. - we continue to do 2.x releases off the trunk until we are ready for 3.0 - any really important 1.x bug fixes can go into the old 1.x branch and we can do a new release from that would people agree to that? i also have a few comments on the points that Anil made below. On Tue, 2005-08-09 at 07:25, Anil Gangolli wrote: > (1) Much much better test automation and coverage, including the upgrade > path. New code => new tests with good coverage. i agree that we need good test automation, but it's also true that with smaller releases we introduce less chance errors and therefore testing becomes a smaller task as well. we all hate testing huge code changes which is one of the reasons to support smaller and more incremental releases. > (2) Strict non-breakage policies on the trunk. Successful build = full > test passage. i'm not sure i agree here. obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways? i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete. > (3) Establishing a practice of developing new features very completely > on branches, followed by an integration/test cycle wholly on the branch > before integration back to the trunk. Branch development could span > multiple release cycles on the trunk. i think this is very reasonable. -- Allen > > One can argue these are healthy directions to push in anyway (I would > certainly support that), but the fact is we're not nearly good enough at > these now to make a jump to short release cycles right away. > > --a. > > > Matthew P. Schmidt wrote: > > > Hi guys. I don't have any voting rights in Apache, but I do run the > > largest public installation of Roller (to my knowledge), so I figued > > I'd chime in. While I'm a strong believer in release early, release > > often (we do it at JL all the time), when there are others using your > > application who have to upgrade/migrate, it isn't always the best > > choice. We all know that upgrades never go as smoothly as planned, > > even with the best designed software, and when things require database > > changes, it gets even worse. It seems to me that you'll be leaving > > out a large group of users by not making bug fixes to old releases and > > by forcing them to deploy new versions every month if they want to > > stay with the supported and stable release. > > I also have to agree with the problems listed for monthly > > deployments. That's a pretty short lifecycle to be developing new > > features, testing them, and deploying them. At that pace you'd almost > > have 1.1 and 2.0 back to back in a month (extreme I know, but could > > have been possible). > > > > Anyway, those are my thoughts, if I had a vote, I'd stick with > > slightly longer release cycles. > > > > Matthew P. Schmidt > > Vice President of Technology > > Javalobby.org > > Email: [EMAIL PROTECTED] > > Phone: 919.678.0300 > > > > > > > > Dave Johnson wrote: > > > >> My group (the blogs.sun.com or BSC team) at Sun believes pretty > >> strongly that small incremental releases are easier to document and > >> deploy than large ones. Following this philosophy, we deploy new > >> features to our sites on a monthly basis. This presents some > >> challenges for us because work directly with the Roller code-base > >> and we don't maintain a separate fork of Roller. > >> > >> I had been thinking that BSC would deploy each month, operating off > >> of SVN HEAD, but the Roller project would make releases every couple > >> of months -- when new features justify a release. Each major > >> Roller release (e.g. 1.2) would happen in a branch and would get one > >> or more bug fixes releases (e.g. 1.2.1 and 1.2.2, etc.). I thought > >> monthly releases were too frequent. My reasoning was this: > >> > >> * Nobody would want to track the monthly releases > >> * Users who don't track will have more difficult upgrades > >> * Users who have deployed existing releases expect bugs to be fixed > >> in those releases > >> * Users would want to stick with major releases for a long time > >> > >> But there are problems with that. One problem is limited resources. > >> Since BSC folks (Allen and I) are busy making monthly deployments, > >> we have limited time to participate in the testing, documenting and > >> releasing of big every-couple-of-months releases. We also have > >> limited time (and limited interest) to work on fixing bugs in old > >> releases of Roller. > >> > >> Long story short, the BSC team is now pushing for monthly Roller > >> releases to match the monthly BSC deployments. As a BSC team member, > >> I have to advocate this and that is what I'm doing by writing this > >> email. But as an independent Roller team member, I'm undecided. I'm > >> not sure how I'd vote, so please help me out with some lively > >> discussion. > >> > >> So, let's say the Roller project makes monthly releases. What are > >> the implications? > >> > >> * The SVN HEAD must be very near stable at all times because a new > >> release is never more than a month away. Any large development that > >> takes more than a month must occur in a separate branch (as we're > >> doing with Roller 2.0 / group blogging). > >> > >> * It is no longer feasible to make bug fixes to old releases of > >> Roller. The way you get new bug fixes is by keeping current on Roller. > >> > >> * To make it easy for users to keep up with Roller we'll need to > >> limit the frequency of database schema changes and when schema > >> changes do occur, the database upgrade must be automated and trouble > >> free. > >> > >> The advantages of release early, release often are well known so I > >> won't cover them here. You can read what ESR has to say about the > >> philosophy here: > >> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ > >> ar01s04.html > >> > >> So my questions are: > >> > >> * How does the Roller community feel about monthly releases? > >> * Is there any Apache policy that is relevant to this discussion? > >> * How do we use the Apache voting rules to resolve this? > >> > >> > >> - Dave > >> > >> > >> > >> > >> > >> > >> > >> > > > > >
