On Mon, Apr 2, 2012 at 23:19, Daniel Kulp <[email protected]> wrote: > On Monday, April 02, 2012 11:11:45 PM Andreas Veithen wrote: >> On Mon, Apr 2, 2012 at 19:04, Daniel Kulp <[email protected]> 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 <[email protected]> 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 >> >> > [email protected] - http://dankulp.com/blog >> >> > Talend Community Coder - http://coders.talend.com >> >> > >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> > >> > -- >> > Daniel Kulp >> > [email protected] - http://dankulp.com/blog >> > Talend Community Coder - http://coders.talend.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
