ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Axiom/Neethi releases....
Date Wed, 04 Apr 2012 21:40:56 GMT
On Mon, Apr 2, 2012 at 23:19, Daniel Kulp <dkulp@apache.org> wrote:
> On Monday, April 02, 2012 11:11:45 PM Andreas Veithen wrote:
>> On Mon, Apr 2, 2012 at 19:04, Daniel Kulp <dkulp@apache.org> wrote:
>> > Andreas,
>> >
>> > On Wednesday, March 28, 2012 10:39:27 PM Andreas Veithen wrote:
>> >> I will work on this during the weekend.
>> >
>> > I saw a bunch of commits.   Is a release of this happening real soon?
>>
>> The vote for 1.2.13 is now open. Originally I wanted to finish the
>> release yesterday, but it took a couple of hours longer. Anyway, I
>> don't like to release something on April 1st ;-)
>
> Ah.  Good point.   :-)
>
> Major thanks.   I'll review things tomorrow.
>
>> > If
>> > not, I'll probably back the one change out (rev 1180609)  for the time
>> > being so we can proceed with the Neethi release.
>> >
>> > BTW:  this is really why I hate having dependencies on SNAPSHOT's unless
>> > we know a release of that SNAPSHOT is imminent.
>>
>> There are as much pros as cons here. E.g. if one wants to identify
>> regressions early, then the best is to depend on the snapshot version
>> of a dependency.
>
> Yes, but not CHANGES in the snapshot.   Basically, be able easily go  back
> to the last release if a release is needed.    I don't mind having Jenkins
> or whatever building against the snapshots to test things.   Definite value
> there.  But I don't like having it rely on new api's and such in the
> snapshots unless we know a release is coming real soon.

General answer:

That would assume that you only use a feature in a downstream project
if it has been released in the upstream project. That is not always
realistic because in some cases it is not possible to validate a new
feature without actually using it in downstream projects. Here I'm not
talking about validating that the feature works as designed (that's
always possible with an appropriate set of unit tests), but validating
the design itself. In particular, when introducing a new API in a
mature project, you need to make sure that the API is sufficiently
flexible and future proof, and that it covers all use cases that you
can anticipate. Often, that is not feasible without using it in
downstream projects to check how this works out in practice.

The only way to satisfy the needs of both upstream and downstream
projects is to use at least two branches, where the trunk can use
unreleased features and where a change is merged to a maintenance
branch only when they have been released.

Pragmatic answer:

In the particular case we are discussing here, actually I thought
about that question when I made that change. As you have noted it
would have been easy to temporarily remove the change and reapply it
after the release, so that this would never have become a blocking
issue for Neethi.

> Dan
>
>
>>
>> > Dan
>> >
>> >> Andreas
>> >>
>> >> On Fri, Mar 23, 2012 at 14:20, Daniel Kulp <dkulp@apache.org> wrote:
>> >> > The shade plugin was released earlier this week so that issue should
>> >> > now
>> >> > be resolved.   Is there any chance of getting the Axiom release done
>> >> > soon so that we can get the Neethi release done as well?  I'd like
to
>> >> > include it in the next CXF release if possible.
>> >> >
>> >> > --
>> >> > Daniel Kulp
>> >> > dkulp@apache.org - http://dankulp.com/blog
>> >> > Talend Community Coder - http://coders.talend.com
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> > For additional commands, e-mail: dev-help@ws.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: dev-help@ws.apache.org
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org - http://dankulp.com/blog
>> > Talend Community Coder - http://coders.talend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.org
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

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


Mime
View raw message