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
nomenclature.
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.
[1] http://download.eclipse.org/eclipse/downloads/build_types.html
--
Regards,
Igor
On 2/18/2014, 19:23, Stephen Connolly wrote:
On 18 February 2014 23:58, Jason van Zyl <ja...@takari.io> wrote:
On Feb 18, 2014, at 3:20 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> 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 of
an
ask for you.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
