As Sean said the mistake here is that shared was not tagged. Let's move on. Don't feel bad, you made changes to trunk and it is unreasonable to expect it to stay compatible w/ the branch. This would happen to someone eventually. I am glad it happened in a big way so that it didn't happen in a small way (which might make it into a lot of people's applications).
The release process *has* to be more than a week. Unless we had every single guy on the team testing and patching (and we do not), releasing a week old branch is like releasing a nightly build. I still don't see where the confusion is though. It goes tag, branch, test, fix, test, fix, release, and merge fixes to trunk. Meanwhile, those developers interested in adding features or architectural changes (such as your recent refactoring spree) can continue to do so w/out interruption (outside of the tags/branches). The project should not have to stop moving forward during this time. Right now the best solution that I see is to tag shared as close to the core tag as possible ( speaking of time here ). I am still trying to find problems with this idea. BTW, some of my work from last week did not make it from commons to shared - nothing massive. Also, I am looking at eclipse right now and all I see for shared is shared-core, shared-impl and shared-tomahawk. I have written an abstract test that I want to extend from core *and* tomahawk. Where does this go? Dennis Byrne >-----Original Message----- >From: Mario Ivankovits [mailto:[EMAIL PROTECTED] >Sent: Monday, March 6, 2006 01:47 AM >To: 'MyFaces Development' >Subject: Re: Testing Progress? > >Hi Dennis! >> I respect your opinions Mario but I'm afraid we don't see this the same way. >Ok. Its just a discussion :-) > >> I tend to lean towards *more* time between branch/tag and release. During >> that time, no new features - only bug fixes that are moved to trunk after >> release (at the latest). >> >+1 to no new features, but I dont understand why we should do this on >the branch. >This requires that we all checkout the correct branches and work on them >during the whole test phase. Just to merge them with the trunk then - >which is error prone. >Why cant we just sensibilize the developers to not add new features to >the trunk during the release process (which should not take more than a >week) >and then create a e.g. 1.1.2-RC1 and so on until the vote for the >release goes through. > >No merge back required. Less work after the release, development can >continue immediately. > >Ciao, >Mario > >
