Re: release 2.3.0 plan
Hi, On Fri, Aug 7, 2009 at 10:49 PM, Marshall Schorm...@schor.com wrote: See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 I was browsing the release plan and noted the following: After freeze, release candidates will be tagged from trunk. Fixes only in trunk, no fixes in tag. Between freeze and release, trunk is not used for development (we're frozen), but development can continue on branches, if needed. That's fine if you've already been following such a code freeze model and are happy with it. A more typical model I see is where a release branch is created from the trunk when the code freeze begins. This way development in trunk can continue normally while the release branch is being frozen and only receives important bug fixes and release management tweaks. Any release candidates would be tagged from the release branch instead of the trunk. BR, Jukka Zitting
Re: release 2.3.0 plan
Jukka Zitting wrote: Hi, On Fri, Aug 7, 2009 at 10:49 PM, Marshall Schorm...@schor.com wrote: See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 I was browsing the release plan and noted the following: After freeze, release candidates will be tagged from trunk. Fixes only in trunk, no fixes in tag. Between freeze and release, trunk is not used for development (we're frozen), but development can continue on branches, if needed. That's fine if you've already been following such a code freeze model and are happy with it. A more typical model I see is where a release branch is created from the trunk when the code freeze begins. This way development in trunk can continue normally while the release branch is being frozen and only receives important bug fixes and release management tweaks. Any release candidates would be tagged from the release branch instead of the trunk. BR, Jukka Zitting So far, we've always followed that model. I still prefer it, not least because it forces you to concentrate on the upcoming release. --Thilo
Re: release 2.3.0 plan
Hi, 2009/8/26 Thilo Goetz twgo...@gmx.de: So far, we've always followed that model. I still prefer it, not least because it forces you to concentrate on the upcoming release. OK, sounds good. You may want to keep this alternative in mind though for future, often especially in bigger projects it may become troublesome to enforce a project-wide code freeze as contributors and committers from diverse backgrounds may have different agendas and schedules. A release branch is an easy way to limit the impact of the code freeze. BR, Jukka Zitting
Re: release 2.3.0 plan
Jukka Zitting wrote: Hi, 2009/8/26 Thilo Goetz twgo...@gmx.de: So far, we've always followed that model. I still prefer it, not least because it forces you to concentrate on the upcoming release. OK, sounds good. You may want to keep this alternative in mind though for future, often especially in bigger projects it may become troublesome to enforce a project-wide code freeze as contributors and committers from diverse backgrounds may have different agendas and schedules. A release branch is an easy way to limit the impact of the code freeze. Thanks, Jukka. I actually thought about doing it the other way, but wanted to avoid double updates for bug fixes in both the main and release branches. But maybe that's not too hard to do with modern SVN tooling... Also, I wonder about about sometime in the future integrating the maven release plugin. We currently don't use it - it used to have a show-stopper defect for us since we use Eclipse workspaces - resulting in a flat hierarchy for our projects, instead of the nested hierarchy in maven projects. I see that defect http://jira.codehaus.org/browse/MRELEASE-261 may have fixed this now, so we may try again... although I realize there may be additional things we will have to alter to get this to work... -Marshall BR, Jukka Zitting
Re: release 2.3.0 plan
One way we have to ensure that the uima core generification is correct is to use our API with generics, thats why I would like to suggest to move our release a few days and use the time to convert existing code outside of the core. That could be done after the code freeze. Jörn Marshall Schor wrote: I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
Re: release 2.3.0 plan
+1 I'm for doing testing of the new generification because of the difficulty of doing this correctly... -Marshall Jörn Kottmann wrote: One way we have to ensure that the uima core generification is correct is to use our API with generics, thats why I would like to suggest to move our release a few days and use the time to convert existing code outside of the core. That could be done after the code freeze. Jörn Marshall Schor wrote: I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
Re: release 2.3.0 plan
Marshall Schor wrote: +1 I'm for doing testing of the new generification because of the difficulty of doing this correctly... -Marshall What kind of testing do think of ? Jörn
Re: release 2.3.0 plan
+1 for an update to uimacpp On Fri, Aug 7, 2009 at 4:49 PM, Marshall Schorm...@schor.com wrote: I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
release 2.3.0 plan
I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
