Current naming with beta isn't that flexible. We could continue doing a lot of betaX releases or start naming betaX.X. I'm fine with both of them. After we get 2.0 out we can start having 2.0.1, 2.0.2 ... 2.1, 2.1.1, ...., 2.2 and things will get more obvious.
Regarding samples, we can either move them to unreleased/ and move them back as they get fixed or we can just open a ticket with subtasks for each sample to keep track of them. I assume we're now doing a 'minor' release so doesn't really matter at the moment. On Sat, Feb 5, 2011 at 8:44 PM, ant elder <ant.el...@gmail.com> wrote: > Well ok, the current release was going to be called 2.0-beta2,with > where we are now and not having done a 2.0 yet if i want to do a > release now from the current trunk then what should it be called to it > get out with the samples being in the less than perfect state that > they are? And can the current samples be left in or should they be > removed from the binary distribution? > > ...ant > > On Sat, Feb 5, 2011 at 2:44 PM, Florian MOGA <moga....@gmail.com> wrote: > > 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 > >> > > > > >
