I agree with Simon. Cutting releases just to make fixes available for affected users is definitely something we should do more often. Marking releases with major and minor sounds like a good way to signal what type of release it is. It also helps the release review process as we know what to focus on. I'm +1 for this as I believe it enables us to do more frequent releases.
On Sat, Feb 5, 2011 at 4:10 PM, Simon Nash <n...@apache.org> wrote: > ant elder wrote: > >> On Sat, Feb 5, 2011 at 10:45 AM, Florian MOGA <moga....@gmail.com> wrote: >> >>> On Sat, Feb 5, 2011 at 11:58 AM, ant elder <ant.el...@gmail.com> wrote: >>> >>>> Great stuff Florian, thanks for doing that work. >>>> >>>> Some of those I know are relatively easy to fix and its just a matter >>>> of getting around to it. >>>> >>> That's right, some of them are trivial, but some are pretty nasty... I'd >>> consider moving samples like helloworld-js-client-webapp to the >>> unreleased >>> folder. >>> >>> I'll try to find some time on it over the >>>> next days. Some of those don't have unit or integration tests run in >>>> the build is why they got broken but quite a lot of them do but the >>>> tests just aren't testing enough or properly. >>>> >>> >>> Talking about unit tests, I've noticed quite a lot of tests marked as >>> skipped in the maven log... This worries me and I think we should >>> definitely >>> revisit them in the next releases. >>> >>>> I'm starting to wonder if we should find a new sample approach. An >>>> issue is presently anyone can add a sample which may or may not have >>>> doc or tests or work in a standard or unusual way and it gets included >>>> in the releases and then adds to perceived quality seen by users and >>>> release reviewers. Because of that what we often do is delay releasing >>>> until "most" of the samples have been brought up to a reasonable >>>> consistent standard but thats not perfect as it slows down releases >>>> and theres still usually some samples that don't work normally and >>>> without doc which users to find a get confused about. >>>> >>> As I've already mentioned on another thread, I think a code review tool >>> would help a lot achieving more quality in our project. I'd go for no >>> major >>> commits without code review but that might not fit everyones taste. It >>> actually isn't that painful as it sounds. A good percent of the bugs are >>> found, knowledge is transferred, more filtering / brushing up until >>> something actually gets in trunk. It might all determine us to write more >>> quality code, add tests, doc. >>> I'm also thinking that as we're heading to alpha releases, we need to >>> 'freeze' the runtime code and do more maintenance releases (samples, unit >>> tests, documentation). It might not be as fun as doing development in the >>> runtime code but I'm afraid it is the only way to have a quality 2.0 out. >>> Last time I heard, we had good oasis compliance, so I think we can afford >>> doing this. With that in mind, I'd like to propose for the upcoming >>> releases >>> to start spinning a new release right after we're done with another one. >>> >>> One thing we could try is releasing the samples separately from the >>>> main code, a lot of other projects do that, and our SDO releases had >>>> the samples separate. That would mean we could do much more frequent >>>> releases of the runtime code as releases wouldn't get held up with >>>> sample quality issues. Is any one for or against trying something like >>>> that? >>>> >>> I think keeping samples together with the runtime code is a good thing >>> because it forces us to maintain samples as well :) If we split samples >>> from >>> code, I think we're going to run into version mismatch problems and it >>> will >>> be much harder and more painful to do sample releases than it is now. I'm >>> calling -0 at the moment, I'd like to see other opinions as well. >>> >>> ...ant >>>> >>> >>> >> Consider a hypothetical example: >> >> Raymond commits a fix for the pass-by-reference enhancements mentioned >> earlier this week and really wants to get the fix out in a release for >> his users to use. >> >> Wouldn't it be better to be able to release that right now instead of >> having to wait for weeks or months while we tinker about with samples? >> >> ...ant >> >> >> It depends on who is the audience for the release. > > 1) If the release is going to be consumed by existing Tuscany users, who > are familiar with the technology and have already developed applications, > these people don't need working samples and would like to get the fix. > > 2) If the release is going to be consumed by people who are interested > in Tuscany and SCA and are evaluating the technology with a view to > possible adoption, doing a release without samples (or with non-working > samples) is likely to put these people off Tuscany because they won't > be able to understand what it is and how to use it. > > At this stage I believe that Tuscany/SCA adoption is still in the growth > phase and therefore the audience for category 2) should exceed that for > category 1). If not, I would be very concerned. > > Could we have the best of both worlds by doing "major" and "minor" > releases as follows? > major release N: contains samples that work > minor release N.1: fixes to the runtime, without new samples > minor release N.m: as above > major release N+1: adds more samples that work, and functional > enhancements > minor release N+1.1: fixes to the runtime, without new samples > minor release N+1.m: as above > > The N.m designation isn't meant to dictate what the releases are called. > > Simon > >
