On Jun 24, 2012, at 1:25 PM, Romain Manni-Bucau wrote: > Regarding "Library changes with no JIRA": when i update a version i often > think "we'll update it again before next release" --> do we create 2 > tickets? or do we simply make a diff between 2 releases?
If you update a library a second time before release, just update the JIRA you created. > about maven plugins they depend on openejb or tomee so i think it will be > hard to release a useful plugin today. Maybe the scan.xml one? That can be a good start. -David > 2012/6/24 David Blevins <[email protected]> > >> >> On Jun 22, 2012, at 6:00 AM, Jean-Louis MONTEIRO wrote: >> >>> Hello guys, >>> >>> We don't have so much external dependencies in SNAPSHOT, and we have been >>> doing a lot of fixes and enhancements since latest release (April, 27th). >>> I would to push a new release up. >>> >>> WDYT? >>> If yes, I'm also candidate to give it a try. >> >> Love it! In practical terms starting with the whole server is a bad place >> to start -- even with the tools it's a lot of hours. That doesn't mean >> there isn't a ton of work that could be shared. In fact much of the tough >> work around doing releases is there are a lot of "i"s that need dotting and >> a lot of "t"s that need crossing. >> >> Things that make releases hard that all of us can help with: >> >> - Changing the libraries in the server and not updating the LICENSE and >> NOTICE files >> - Huge volumes of commits without JIRAs -- there's no possible way >> something in there shouldn't go into the release notes. We're getting a >> bit better with this but more needed. We need to each of us be watching >> commits and nudging our fellow committers when we see a non-trivial commit >> that has no JIRA >> - JIRAs filed but not closed or not marked for the target release >> - Missing headers on source files >> - Library changes with no JIRA >> - Get version numbers out of code. Ideally we would not have any version >> numbers outside of pom files or the ant build.xml files. Fixing that is >> really a coding task not a releasing task. >> >> So all of the above are up for grabs by anyone at anytime. The more >> proactive we are with these things during the development cycle the easier >> things will be at release time. >> >> Maybe get started with some of the above and we'll see how far we get. >> >> In terms of right now, maybe if there's a maven plugin we could pull out >> and release this week that would be the best place to start you down the >> release path in terms of the actual logistics of releasing -- gpg >> signatures, working with nexus, etc. Basically the same as we did for >> Romain. >> >> Thoughts? >> >> >> -David >> >>
