Jason van Zyl wrote:
On 30 Sep 07, at 12:41 AM 30 Sep 07, Stephane Nicoll wrote:
On 9/29/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Why, and says who? These things are not cast in stone and we have the
ability to adapt the process to make it more productive.
[...]
I don't really care. Staging a release is not a big deal, just
invariably pointless for an alpha because 99% of the time no one will
actually do anything with the staged copy. It's more important that
the stuff gets cranked out for feedback so it can be fixed. I mean
even with releases hardly anyone looks. It's nice idea in theory but
if it serves no practical purpose what is the point. I was hopeful
that the staged copy would illicit feedback but doesn't seem to have.
Not much anyway.
I agree with you but, even if those things are not cast in stone, it's
commonly used. If we were to adapt for alphas, betas or anything else,
I think it makes more sense to discuss it a bit instead of doing it on
your side without telling anyone.
That's not the first time you're doing this and it's personally
confusing to me.
All I want is a mechanism that encourages more use in the intermediary
stages.
It takes more then a week to push out subsequent releases for an alpha,
the release plugin gets incrementally worse and has been breaking things
on subsequent releases itself because it's not tested enough before
pushing it out the door making the whole process more painful. The
staging plugin was never meant as a solution and it's not all that great
either.
We are a project which encourages the use of binaries and agile
development. We don't have an easy for people even to test in certain
cases. If you start with no local repository and repositories in your
settings activated by a profile with repositories it is unworkable. For
tools like Archetype where you start with no POM the settings won't be
used and there is no way to test it other then to give someone an
archive they have to unpack locally or they have to build it themselves.
Neither of these options are fantastic.
Between our release model taking so long, people historically not
looking at releases (which is normal people don't have a lot of spare
time to look at everything), our tooling not being quite up to snuff,
the staging plugin being a stopgap, and the release plugin breaking
things with subsequent releases (though Dan is working on the GPG
plugin I see) it becomes very hard to get these changes out to users to
utilize and provide feedback. If we don't make this easy, fast and
painless for users we lose them. A user having to wait 3 days to try a
bug fixed version of an alpha while a developer is focused on it is
painful. To be able to release it as it would be used in the wild is the
best way.
I have three very large clients who are very flexible in that they would
try alphas of certainly things in their lifecycle. But they will not
build from source, they will not introduce snapshot repositories into
their builds in order to consume changes. Build from source is just not
an option for a team who is suppose to be consuming this technology.
Using snapshot repositories is just too unpredictable given the current
mechanism, though I have tried to use them in order to consume changes
it's just not practical given the instability so snapshots repositories
have been ruled out.
The groups that I'm working with cannot be the only groups like this in
the world. If more alphas were produced it's very easy with a good
parent POM to change the version and attempt using an alpha in a build.
I would like to be able to crank out alphas as fast as humanly possible
so we stop losing this feedback. I want to make the alpha process less
painful for users so that more things are found so that it is possible
to have betas that have been suitably tested. This simply is not the
case with our plugins because we are missing feedback during the entire
span of time between releases.
I am pleading with you guys to help not make this process painful, tied
down with bureaucracy and get incremental changes out in a usable form
which Maven users are accustom to consuming. Building from source and
snapshot repositories are just too much to expect from users who are
simply trying to verify that issues have been corrected. It is
unfortunate that using snapshots it is not clear what you are going to
get but that's the situation we have right now and I think we would do
ourselves a great service to:
1) Reduce the time required to release alphas i.e. take three +1 votes
and kick it out
2) Realize that people do not have a lot of time here and the process of
waiting 3 days is not adding much value because I would argue that the
second the vote goes up anyone really interested is going to look at it
very shortly
3) That in order for changes to be consumed by average users who are
willing to give us feed back it has to be easy to use these changes.
I would argue that no wait is required for alphas, but that for betas
and releases 3 days is not enough because people don't scrutinize them
enough. So this 3-day wait kills us from being agile in the realm of
alphas, and is way to short for a production release. This doesn't
happen because we can't get the feedback during alphas to ensure that
releases are production quality.
I want to enable our users to help us. We need less rigor in the early
incremental stages of new releases and more rigor when it comes to
production releases.
I agree - I've always thought of alphas are little more than tagged relatively
stable snapshots.
There are benefits in making more agile the alpha release cycle.
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
