maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <>
Subject Re: Towards faster releases
Date Wed, 19 Feb 2014 02:09:35 GMT
Eclipse development process distinguishes several build types [1], so I
am wondering if you really want to do weekly "full" releases or your
goal is to have something closer to integration builds in eclipse

I see two major downsides doing weekly full releases.

First, one week just is not enough to do any meaningful API work. For
example, it took way more than a week to agree on API related to mojo
execution scope I've introduced in 3.2. If new "full" release is
declared every week, this means all API work will have to happen on
feature branches, which may have exact opposite affect to what I believe
you try to achieve -- the code will sit untested, unreleased and
ultimately unused longer simply because there will be more branches to
test and review.

Second, it takes me between half a day and a day to test new maven
release. This includes testing maven itself as well as testing maven in
the context of m2e. I simply can't afford spending this much time every
week, so won't be testing every release. I won't be able to integrate
each new maven version in m2e either. I obviously don't know for sure,
but if I were to guess, most other maven developers are in the same
position and will not be able to do proper release testing every week.

So going back to my initial Eclipse dev process reference, I don't see
any harm releasing semi-automated weekly "integration builds", as long
as we clearly communicate level of testing and API stability these
builds offer. As for "release" releases, my preferred cadence is 8 weeks
to 3 months.



On 2/18/2014, 19:23, Stephen Connolly wrote:
> On 18 February 2014 23:58, Jason van Zyl <> wrote:
>> On Feb 18, 2014, at 3:20 PM, Stephen Connolly <
>>> wrote:
>>> Well for one that is not how RM works or has worked here.
>> Really? When I have planned to release core it takes some effort that
>> requires more effort than the normal components. So if it's not clear from
>> trying to curate the issues for the next release and working on the core
>> with the intent to release 3.2.2 when those issues are complete.
>>> It's not a hat you keep. It is a hat you put on when you send the mail
>>> saying "I am intending to cut a release in the next _ days"
>> All implied, nothing stated and I have always done a series of core
>> releases because otherwise the overhead is generally pretty high. For a
>> plugin maybe you can just do a couple days work and do a release but this
>> is not how it works for the core.
>>> If somebody objects then you take that on board as you see fit. Any
>>> committer can step up and say they intend to cut a release of our
>>> components. There is no persistent or sticky RM role.
>> You assume that the core RM is not sticky, I assume it is. If there is a
>> huge gap sure, and like I said if after this 6 month gap you want to ask
>> the group to have a new RM then you can. Otherwise I viewed it as implied
>> with the work done of late that I am the RM for the next core release. So
>> I'll state it explicitly that I plan to release 3.2.2.
>>> I am happy with you cutting releases of core... in fact I am happy with
>>> anyone who isn't me cutting releases of core or any plugin... largely
>>> because it means less work for me...
>>> There is, however, a problem if we don't get more people acting as RM for
>>> any releasable from our project...
>>> If you haven't cut a release, you fear the unknown involved in cutting a
>>> release.
>>> My aim is to make releasing Maven core a non-event and trivially easy to
>>> do. That has many benefits, not least making our work easier and getting
>>> fixes into users sooner.
>>> Yes we could start with a less ambitious time frame, but my experience is
>>> that it is easier to start with the small release deltas that come from
>>> short time between releases and slow down if necessary.
>>> If you start with a process that is too fast, you are starting with a
>>> process that is broken and slowing down until it is working.
>>> If you start with a process that is too slow, you are speeding up until
>> it
>>> breaks
>>> I do have to wonder what you are afraid of?
>>> You tend to work in branches and merge features when ready, so if you are
>>> the only one making changes the build will have nothing to suggest until
>>> you merge your branch to master.
>>> If other people have fixes for specific issues, what is wrong with
>> letting
>>> users get those fixes if they want.
>> Any one can fix anything they like. Michael and Robert added some fixes
>> and improvements and they have gone in, and they were basically released a
>> week or two after the fixes went in, but if they waited for a few more
>> weeks I don't really see it as an issue. I have the opposite experience as
>> you and organization's infrastructure does not change weekly, monthly or
>> even quarterly. So taking more time and collecting changes is not a bad
>> thing. I see little to no value for the majority of users and if we want
>> people to try things we should make the nightlies very easy to consume.
>> This does not require official releases. Anyone can get fixes whenever they
>> want if we make it easy. This should just happen automatically and I think
>> is a good thing. Official releases require a support commitment which I
>> consider important and more of them is harder.
>>> I'll make a deal with you, lets see how you feel after 1 month. I suspect
>>> we will maybe have 1 release during the first month anyway... and may
>> well
>>> have none... but if we don't try we will never know.
>> I assumed I am the RM for 3.2.2 and I plan to release it when that list is
>> done. I am vehemently against official weekly releases and this will
>> require a discussion if this is to change. If you want to call them alphas
>> or nightly and we make those easily available I have nothing against that
>> and serves the small segment of the population that will try new things
>> aggressively. If that falls into a pattern of availability for a 6 week
>> release schedule that would be great. Ultimately anything built at any time
>> should be a candidate for a release and those should be available for
>> people to try but I don't think they should be official releases that we
>> officially support.
>> So maybe these are not nightlies but promoted nightlies that have fixes
>> for those who really require them.
> If they are releases that we intend users picking up, then there needs to
> be a vote.
> I don't mind if we call these 3.2.2-alpha-x releases or some other version.
> The simple fact is that -SNAPSHOTs do not get tested. Things called alpha
> or beta don't get tested, and if we want to stick to semver type version
> numbers then 3.2.x is really just bug fixes and anything else is 3.3.x. I
> am not suggesting weekly releases for 3.3.x only for 3.2.x
> So for example MNG-5577, from what I understand, is an API change... a
> backwards compatible one true... but still not a bug fix... so perhaps
> significant enough that it should be 3.3.x... (and remember this experiment
> only targets 3.2.x)
> Precisely because we have held back releases we end up in this state where
> we are afraid to bump minor or major versions because we do not have enough
> changes in them... and then we try to cram more changes into what should be
> patch releases.
> A patch release is to fix a bug... if it is an improvement then IMHO it
> should be in the next minor version... if it is a breaking change then the
> next major...
> If you see a different scope of what should be in for 3.2.2 (or 3.2.3 if
> the vote for 3.2.1 fails) then there is a different disconnect there.
> If we want to show that Maven is listening to users, sticking to patch
> releases fix bugs, minor releases add features, major releases may break
> things is what users want... and if we are only fixing bugs in 3.2.x then
> what is the issue? The bug is fixed, let's get that fix in the hands of our
> users.
>> But if anyone else thinks weekly releases are good speak up. I don't think
>> we can really support them properly. I think 6 week releases would be
>> fantastic and should be the first goal we strive for. Weekly releases to me
>> are not valuable to most, generally not going to be consumed and not a
>> great in practice. Continuous delivery with a stream of viable builds taken
>> from the normal build stream would be great. Let people take those as fast
>> as they can. But releases we should try to have better release notes
>> (historically ours have been pretty terrible, myself particularly,
>> admittedly) and generally a useful collection of fixes and hopefully
>> features. I really doubt anyone would care about weekly Maven releases,
>> it's just too much to absorb.
>>> -Stephen
>>>>> If you want to cut the releases, super. But I recognise that cutting
>>>>> releases is work and switching to (max) one per week may be too much
>>>> an
>>>>> ask for you.
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> ---------------------------------------------------------
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>    -- Jakob Burckhardt

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message