On Tue, Jul 10, 2012 at 10:07 AM, Shenfeng Liu <liush...@gmail.com> wrote: > Hi, all, > Since we are stepping forward to the 3.4.1 release smoothly, I think > maybe it is time for us to look ahead for our next release now. > > I remember we had a discussion previously on how to run AOO's future > releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we > should resume this discussion. > > IMHO, timely release will give AOO a very good promotion to marketing. > Certainly we can decide the size of the release. We released 3.4 at May 8, > and then will release 3.4.1 after about 3 months. It looks like a very good > rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year... > > Another way to consider is the release contents. Checking the feature > requirement list and defect backlog, see what we can make after 3 months or > 6 months. Or if there is any thing must be in the next release no matter > how long it will take (e.g. security fix). We partially did this practice > before by collecting the 4.0 requirements in wiki: > https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning. > And I remember there was a common interesting at that time that we > should > do an immediate release for critical defect fixes (which is 3.4.1 that we > are doing now), and then a mid-term release which majorly target to > fidelity improvements (3.5), and a long term release with Symphony values > on UX and social integrations (4.0)... > > I'm not sure how to do a release proposal. Is that we should create a > project wiki and discuss the release goals, contents, outlook GA date? And > if we agree on this release, we move on. If we do not agree, we abandon it? > > I'm asking because I want to propose that: > > (1) We should begin to check if any critical defects in our backlog that > require us for a 3.4.2. > > (2) We should begin to discuss a bigger release like 3.5 on the release > goals, and proposed contents, and the release number... > > Just my 2 cents... Any suggestion/comments? >
These are good questions. We have many kinds of users, but two big categories of users, with different concerns, might be: 1) Individual users, who self-manage their PCs. They like getting new features and updates. They don't want to wait a year. 2) Corporate users (but also in schools, libraries, etc.) where the PCs are managed by an IT department. They want stable releases, consistent quality. Frequent updates are not very welcome, especially if they bring new bugs. So I think this naturally leads to a two-path approach: 1) Feature work continues in the trunk, and we spin 3.x releases from the trunk. This could be done as frequently as we want to, but each time we do it will have overhead for us and for users. So maybe do this only 2 or 3 times/year. 2) Declare a Long Term Support (LTS) release that we provide critical patch support for, and commit to doing so for a longer period of time, e.g., two years. So users decide for themselves which track they want to be on. If they opt for the feature track, then they will get more frequent releases, with new features, but also new bugs. That is the trade-off they make. And users who opt for the LTS track will get only critical bug fixes, but also no surprises. Microsoft has a similar approach, of course, with a new release every 2 or 3 years, with hot fixes and service packs after each release. In their case the patch support is long-term, 10 years even for Office 2013. But of course the open source ethos is "release early; release often". So we need some way to balance that as well. One technical thing we could do to make this more manageable would be to figure out some way to incrementally update an install without downloading a complete package and reinstalling. This would make the LTS versions much easier to maintain. -Rob > Thanks! > > - Simon
