On Mon, Dec 19, 2016 at 11:24 AM, Manfred Moser <[email protected]> wrote:
> Totally agree. Master should be ready to release all the time imho. > Nothing that isnt tested well and proven to at least pass all IT's should > be merged into master. Experimentation should happen in feature branches.. > I think it's OK to have a master branch that is not ready to release at a moment's notice but it MUST be the case that all tests pass all the time. Gary > > Just my 2c. > > Manfred > > Stephen Connolly wrote on 2016-12-19 11:12: > > > We need to get the project back in the habit of releasing. > > > > My vote is the we rebuild master with a clean history. keep current > master > > as a reference branch, and cherry-pick as we go. > > > > The aim should be kept tight in scope and focus on the aether replacement > > only. Minimum change for aether replacement. > > > > Then we can start bringing in bug fixes. > > > > If we need to break things, we can go 3.6.x or 4.x.y I only request that > > 5.0.0 be reserved for the first release with a modelVersion 5.0.0 pom > > (which is what my proposals are aiming to help us flesh out... though my > > proposals may not be selected by committers in the end, hopefully they > will > > allow us to have a reasoned debate) > > > > Wdyt? > > > > On Mon 19 Dec 2016 at 17:41, Robert Scholte <[email protected]> > wrote: > > > >> We're already trying to push a new release for quite some time. And it > >> > >> seems the discussion is not over yet. > >> > >> There are a lot of improvements which deserve a release, so personally > I'd > >> > >> like to push the discussion to 3.5.0 > >> > >> > >> > >> Robert > >> > >> > >> > >> On Mon, 19 Dec 2016 14:12:25 +0100, Stephane Nicoll > >> > >> <[email protected]> wrote: > >> > >> > >> > >> > Isn't that postponing the discussion we're having here on those > >> > >> > controversial changes? I'd rather give it an extra effort rather than > >> > >> > pushing it back and loosing all the context once we have to tackle > 3.5. > >> > >> > > >> > >> > On Sun, Dec 18, 2016 at 10:02 PM, Stephen Connolly < > >> > >> > [email protected]> wrote: > >> > >> > > >> > >> >> I like that plan, but let's call that 3.4.0 and let these other > changes > >> > >> >> go > >> > >> >> for either 3.5.0 > >> > >> >> > >> > >> >> Does someone want to take a stab at forking master from an earlier > point > >> > >> >> (perhaps get infra to let us rewrite master back to the fork point > and > >> > >> >> push > >> > >> >> the current state to a branch?) > >> > >> >> > >> > >> >> On Sun 18 Dec 2016 at 19:45, Igor Fedorenko <[email protected]> > >> wrote: > >> > >> >> > >> > >> >> > No, I meant just eclipse->apache move, not all changes that went > into > >> > >> >> > > >> > >> >> > maven-resolver. The idea is to have a release branch we can > maintain > >> > >> >> > > >> > >> >> > while things stabilize in master. > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > -- > >> > >> >> > > >> > >> >> > Regards, > >> > >> >> > > >> > >> >> > Igor > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote: > >> > >> >> > > >> > >> >> > > Am 2016-12-18 um 18:44 schrieb Igor Fedorenko: > >> > >> >> > > >> > >> >> > > > I wonder if it makes sense to release 3.3.10 with just the new > >> > >> >> aether > >> > >> >> > > >> > >> >> > > > and give 3.4 more time to bake on master. > >> > >> >> > > >> > >> >> > > > >> > >> >> > > >> > >> >> > > Changing a dependency with so many changes recently in a fix > >> > >> >> version? > >> > >> >> > > >> > >> >> > > Doesn't sound right to me. > >> > >> >> > > >> > >> >> > > > >> > >> >> > > >> > >> >> > > M > >> > >> >> > > >> > >> >> > > > >> > >> >> > > >> > >> >> > > > >> > >> >> > > >> > >> >> > > > >> > >> >> ------------------------------------------------------------ > --------- > >> > >> >> > > >> > >> >> > > 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] > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > -- > >> > >> >> Sent from my phone > >> > >> > >> > >> --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: [email protected] > >> > >> For additional commands, e-mail: [email protected] > >> > >> > >> > >> -- > > Sent from my phone > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
