maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: What is in a version? (was Towards faster releases)
Date Wed, 19 Feb 2014 20:27:46 GMT
I need to remind people about the Apache rules here. Yes you can have
weekly builds. No you can't 'advertise them' in any way that is likely
to attract the attention of mere users as opposed to people engaged in
the development community. Please don't shoot me, I'm just the
messenger here.

On Wed, Feb 19, 2014 at 11:25 AM, Jason van Zyl <jason@takari.io> wrote:
> Agreed, if they small enhancements then I don't really want to release 4 things issues
in a patch release and then another 5. Generally I'm fine with small enhancements, or small
fixes going into patch releases, along with anything marked @provisional as I'd rather have
the experimental code in a release then rotting in a branch.
>
> That said I'm not averse to calling the next release 3.3.0. A 3.2.2 isn't strictly semver
and I certainly would like to have this for 4.0.0 but right now I don't have a strong opinion.
If we want to decide to use semver (which we never have) and want to try now that's fine.
We need to get there at some point.
>
> But I'm still off the mind the best approach is what Igor outlined. No official weekly
releases, we just make the infrastructure work to publish weekly integration builds and let
people consume them as required, and any changes in those get rolled up into official release
schedule.
>
> On Feb 19, 2014, at 6:36 AM, Paul Benedict <pbenedict@apache.org> wrote:
>
>> I don't see any necessity to restrict patch releases to patches only -- as
>> long as any new functionality is a tiny enhancement and doesn't make
>> incompatibilities. Save medium/major structural changes for a new minor
>> version.
>>
>>
>> On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies <bimargulies@gmail.com>wrote:
>>
>>> A bit of a recap:
>>>
>>> Let's say that our goal as a group was to be very responsive to user's
>>> bug reports.
>>>
>>> So, we'd want to make fixes and releases, 'promptly', for some
>>> definition of prompt.
>>>
>>> But no one will install those releases if they are not confident that
>>> they are, in fact, not going to have unexpected consequences.
>>>
>>> From a black-box standpoint, this can only be achieved with really
>>> strong integration tests.
>>>
>>> From a white-box standpoint, it seems to me that the Maven core has a
>>> tendency towards complex interactions in which a fix to problem (a)
>>> can have unexpected consequence (b).
>>>
>>> So, either way, Jason's views about testing seem spot-on. This leaves
>>> a question: should we be trying, still, to follow up a 3.2.0 with a
>>> pure bugfix 3.2.1, and holding off on structural repairs or new
>>> features until 3.3? One view is that we should try to get some of the
>>> tests improved and some of the structural repairs done before we make
>>> any attempt at semver/responsive releases. The other view is that
>>> should try to deliver on semver as best we can.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Paul
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message