I'm with Kristian, as if he needs any help here. We aren't anywhere near where we'd have to be to feel confident that a release of some component was guaranteed regression-free in all obscure cases.
One small thought: if people would mark their votes 'binding' or 'nonbinding', it would reduce the effort of collating them. The easier the process is, the more releases we can make. I'm always happy to rm. On Tue, Jun 21, 2011 at 2:57 AM, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote: > Technically I'd get away with updating 2-3 artifacts, but I'd end up writing > a cookbook on how to add a crapload of dependencies to the plugins in > question and answering on the mailing list and irc, and in the end we'd have > a ton of poms lying around with 3 overridden dependencies in 4-5 plugins. So > as as service to our end users I think the fair thing is to release new > versions. Now given that we manage to maintain an "average" release schedule > of 4-8 weeks, I would probably just ignore releasing the plugin, but > currently I think our release schedules are driven by itches like mine. So I > suppose we *could* solve this by just assigning regular releases to > committers. Personally I don't /mind/ taking responsibility for releasing > 2-3 plugins every 6-8 weeks if I knew someone else did the others. > > I think version ranges for plugins are fairly dangerous because you'll be > removing the determinism in the build. Even though you lock down plugin > versions, you risk getting a new version of maven-shared-foobar any day. I > just need introduce *1* platform specific bug in maven-shared-foobar to > paralyze the entire community of "windows" users. I've seen this happen in > other projects that (for instance) have *no* committers working on windows > (yes, it's becoming fairly commonplace). > > Kristian > > > > Den 21.06.2011 02:38, skrev Brett Porter: >> >> Kristian can describe in more detail what he's working on, but not all >> changes take 8 artifact changes. In this case I think it's both that it's >> something that affects multiple things (rather than dependencies), and also >> a couple of things that have been broken down to one too separate many >> artifacts (like plexus-compiler, which I think is only ever used in the >> compiler plugin). Those sorts of exercises should actually help us >> understand if the right type of modularity has been applied. >> >> - Brett >> >> On 21/06/2011, at 6:27 AM, Mark Derricutt wrote: >> >>> Wow - that seems like a hell of a lot of releases having to be made... >>> >>> This post is probably drifting off topic but the thing that strikes me >>> here >>> is that this is the exact reason why maven supports version ranges - so >>> that >>> you don't have to make a plethora of rolling releases just because one >>> change was made downstream. >>> >>> It's no wonder a lot of version range bugs in maven never get fixed if >>> none >>> of the plugins or maven itself actually uses them. Of course this only >>> solves the problem where an upstream release contains non-breaking >>> changes >>> for its downstream users which hopefully, for bug fixes would be more >>> often >>> than not. >>> >>> Locking down versions is good for third party dependencies, but I'm very >>> much of the mind that ranges should be used for sibings, would certainly >>> solve the problem of transitive release blowouts. >>> >>> >>> -- >>> "Great artists are extremely selfish and arrogant things" — Steven >>> Wilson, >>> Porcupine Tree >>> >>> >>> On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold< >>> kristian.rosenv...@gmail.com> wrote: >>> >>>> >>>> Den 19.06.2011 23:08, skrev Gavin McDonald: >>>> >>>> >>>>> I would be happy with weeks to be honest. Then again I have been used >>>>> to >>>>> being around >>>>> slower projects that have released only every 2 or 3 years once 1 or 2 >>>>> hundred issues have >>>>> been gathered into a release. And the release process itself takes >>>>> weeks >>>>> of work to >>>>> achieve. >>>>> >>>>> Therefore ignore me, 3 issues seems like doing a days work, then >>>>> release, >>>>> then another days >>>>> work, then release etc ... >>>>> >>>>> >>>> Given a very quick count, the apache maven project contains something >>>> like >>>> 90 individually deployable and separately votable artifacts. Our users >>>> upgrade these components individually according to need. Each component >>>> is >>>> individually tested and voted for; maven is not a monolithic application >>>> and >>>> should not be released as one. >>>> >>>> The downside of this componentization is that sometimes fixing a single >>>> issue leads to the redeployment of multiple artifacts, at the moment I'm >>>> working on 1 issue that will require the >>>> redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) >>>> before it's closed in its full extent. Most likely I'll have votes for 2 >>>> of >>>> these "soon" and I'll just let the remaining 4 roll out >>>> together with releases planned by others. But in this context I simply >>>> refuse to consider if a single release vote is too large or too small. >>>> >>>> From an agile perspective there's potential to getting a lot more >>>> issues >>>> fixed with a single year than the kind of project you mention. I have no >>>> specific stats but I assume we fix at least a thousand issues every >>>> year. >>>> >>>> Some of our projects have sufficiently good automated test coverage that >>>> I >>>> suspect we could allow incremental .1 releases to go without a vote >>>> entirely. I'm not sure if this is something we're even allowed to >>>> consider >>>> ;) (Surefire would probably qualify, assuming we did some kind of >>>> formalized >>>> "continious production" kind of review) >>>> >>>> I think ideally we should release every top-level component every 6 >>>> weeks >>>> or so. But that means we'd have 1-3 votes every day ;) >>>> >>>> >>>> Kristian >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------**------------------------------**--------- >>>> To unsubscribe, e-mail: >>>> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> http://au.linkedin.com/in/brettporter >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
