The users may well be developers, but I don't think that warrants
changing
a normal pattern. Maybe only I consider this a normal pattern, but I
don't
know of any examples, personally, where externally represented versions
have gaps in them. I'd ask you the same question I asked Stephen as to
whether you know of any projects, or products, that do this? Just
because
we can skip versions isn't a good reason to do so. If lots of projects
do
it then it's worth considering. Have any examples on hand?
For now while I'm doing the core releases, I would prefer not to have
gaps. Call me provincial, but I'd like to do what we've always done
since
the inception of the project unless there is a compelling reason to do
otherwise.
On Sep 14, 2013, at 7:48 PM, Fred Cooke <fred.co...@gmail.com> wrote:
> Jason, PLEASE understand that you do NOT have a single user. Not even
one.
> Nada. Zilch. You have developers. Developers, by definition, are not
> *completely* stupid (though some try to fool us!). They can handle
missing
> versions. If you released firefox 12 after firefox 10 it would be
confusing
> for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
> moron would be confused by this. Few developers are that stupid, and
those
> who are have limited months of career as a dev ahead of them. "it's
> confusing" holds no water in the context of a hard-core dev tool IMO.
>
>
> On Sun, Sep 15, 2013 at 1:34 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> The difference is that you say those versions did not pass QA.
>>
>> As a user I'd rather know that what I have *unabiguously* passed QA
>> (whatever that QA process is, and however lax it is) than know the
>> increasing version numbers. On top of that, if we go increasing,
with no
>> skips, we are actually giving people a false sense of extra QA... By
>> telling people "go to this page where we list the status of each
version"
>> then they will not be confused at all... Instead they get greater
>> confidence...
>>
>> They will see
>>
>> * some versions we never released a binary for... Those were really
bad
>>
>> * some versions we released a binary for... And then found critical
bugs is
>>
>> * some versions we released a binary for, but its only recent so
there
>> could be regressions our test suite missed
>>
>> * some versions we reased a binary for, have had no serious issues
raised
>> for the past 6 weeks and are considered stable
>>
>> * some versions we no longer recommend
>>
>> As a user such a page gives me much more confidence in the project
rather
>> than our current "every release is a release" lase fair attitude that
saw
>> 2.1.0 pushed as the latest for longer than was healthy given the
artifact
>> signing issues. As a user it also gives me more confidence that once
I
see
>> a new release transition to stable (say 6 weeks) or recommended (say
3
>> months) that I am following the project guidelines
>>
>> I am not saying the version would be missing (the tag would always be
>> there) but that a binary or source dist would not...
>>
>> Everyone is entitled to their opinion... previously it was Maven
developers
>> who said no missing version... Iirc you are the first to suggest
users
>> would be confused.... Have we actually asked users which is more
confusing?
>>
>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>
>>> I don't agree. I think this would be massively confusing to people
if a
>>> version was missing, or several failed and you went from 3.1.0 to
3.1.3.
>> I
>>> don't think that would make much sense to most users.
>>>
>>> On Sep 14, 2013, at 5:49 PM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>>> On Saturday, 14 September 2013, Dennis Lundberg wrote:
>>>>
>>>>> JIRA is not a big problem. Say for example that the 3.1.1 release
was
>>>>> abandoned due to some problem, you would simply rename the
version in
>>>>> JIRA from 3.1.1 to 3.1.2.
>>>>
>>>>
>>>> Exactly.
>>>>
>>>> Not a problem if you ask me... The only one I can think of if the
>> javadoc
>>>> @since tags and even without skipping versions they can end up at a
>>>> unreleased version label, plus they are just a >= which will be
valid
>>> anyway
>>>>
>>>>
>>>>>
>>>>> On Sat, Sep 14, 2013 at 10:34 PM, Mark Struberg
<strub...@yahoo.de>
>>> wrote:
>>>>>> I think it's mainly because the maintenance and housekeeping
costs
on
>>>>> the JIRA front and others which use the version nr as reference.
>>>>>>
>>>>>>
>>>>>> Imagine that you would need to move all the JIRA tickets which
got
>>>>> marked as fixed in a certain release as well. Otherwise the
release
>>> notes
>>>>> would be broken - or would need to get maintained manually.
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Fred Cooke <fred.co...@gmail.com>
>>>>>>> To: Maven Developers List <dev@maven.apache.org>
>>>>>>> Cc:
>>>>>>> Sent: Saturday, 14 September 2013, 21:51
>>>>>>> Subject: Re: Leaving Maven Core POMs at major.minor-SNAPSHOT
>>>>>>>
>>>>>>> I agree on skipping failed versions! I was avoiding the topic
>> because
>>> it
>>>>>>> seemed popular opinion was to re-spin endlessly like a child's
>>> spinning
>>>>> top.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Sep 14, 2013 at 9:47 PM, Stephen Connolly <
>>>>>>> stephen.alan.conno...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Why as long as you don't push the tag, there's no big deal.
Pushing
>>>>>>> the tag
>>>>>>>> is when problems appear... In any case I'd prefer to just skip
>> failed
>>>>>>>> version numbers... Though I was voted down last time that came
up,
>>> and
>>>>>>>> given I'm not running too many releases at the moment, I don't
see
>>>>>>> my
>>>>>>>> opinion as being heavyweight on that subject... Version numbers
are
>>>>> cheap
>>>>>>>> and we've had borked releases before (eg critical IMHO bugs in
>> 2.1.0,
>>>>>>> 2.2.0
>>>>>>>> and 3.1.0...) so I don't buy the "what if a user checks out a
tag
>>>>>>> that was
>>>>>>>> not released" argument.
>>>>>>>>
>>>>>>>> In my opinion we need a release status page anyway, eg stating
>>> whether
>>>>>>>> specific versions are considered stabilising, stable, retired
or
>>>>> advised
>>>>>>>> not to be used... Such a page would remove the need for
recycling
>>>>> version
>>>>>>>> numbers *and* provide benefit to users at the same time.
>>>>>>>>
>>>>>>>> But I will leave it for others to fight the relative costs of
>> version
>>>>>>>> numbers (given the infinite supply) against making sure JIRA
>> release
>>>>> notes
>>>>>>>> and javadoc @since tags (which is stupid, @since 3.2.3 means it
>>>>> should be
>>>>>>>> there in the 3.3.0 release that 3.2.3 became, so no fix
strictly
>>>>>>>> required) are correct and saving the risk that a user checks
out
an
>>>>>>>> unreleased tag and tries to build that from source and then
starts
>>>>> trying
>>>>>>>> to raise bugs against a non-exist any version!
>>>>>>>>
>>>>>>>> On Saturday, 14 September 2013, Jason van Zyl wrote:
>>>>>>>>
>>>>>>>>> We need a slight modification of this strategy because the
changes
>>>>>>> need
>>>>>>>> to
>>>>>>>>> be pushed somewhere so that people can examine the tag if they
>> want
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> <javascript:;><javascript:;>
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>> <javascript:;><javascript:;>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Sent from my phone
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
