I would like the 5.0.x branch to be removed completely. The commit does not provide any value at all. I was hopping to start working on 5.0.x in parallel, but this is not what has happened.
Regards 4.2 version in JIRA - it was intention to release 4.1 earlier and release some non-breaking changes shortly after, but again, this has not happened. So, I'm fine with 5.0 straight away. Best Regards, Alexander On Mon, 28 Nov 2016 at 3:38 AM, Edno Silva <[email protected]> wrote: > +1 for .NET 4.6.2 > +1 we should head directly for 5.0. > > 2016-11-27 7:01 GMT-02:00 Ricardo Peres <[email protected]>: > > +1 for .NET 4.6.2, plus replacing System.Data with System.Data.Commom ( > NH-3431 <https://nhibernate.jira.com/browse/NH-3431>), plus updating > ReLinq to latest version - was this done now or just closed? > > RP > > > On Saturday, November 26, 2016 at 11:57:08 PM UTC, Oskar Berggren wrote: > > Hi, > > With 4.1.0 finally getting close we should do some planning for NHibernate > 5.0. > > First of all, there are mentions of a 4.2 release in various places, such > as Jira and Github milestone, but I say we should head directly for 5.0. > > There is already a branch "5.0.x" available with a single commit to make > NH target .Net 4.5.2. Should we merge that to master? Or should we do a > rare rebase of this single commit to current master, for a simplified > long-term branch history? I'm leaning towards the latter, I suspect not too > many will have branches based on 5.0.x already? > > Then I guess we can just as well target .Net 4.6.2 immediately. > > > Some other tasks: > Remove the NET_4_0 conditional. This was mostly for implementations of > ISerializable.GetObjectData(). > > There are a bunch of pull requests queued for 4.2 and 5.0, many of which > should be in good condition already. Merge as many as possible, after that > request rebases of the others. Repeat. > > There are some big items like switching to NUnit 3.0. > > Review other dependencies and upgrade where available. > > I might be inclined to look at porting Hibernate's refactoring of dialects > and id generators. > > > > In a different thread I suggested a more relaxed approach to versioning > and breaking changes, that would consist of making 4.1 the current > long-term API stable release, while releases 5.0, 5.1, 5.2 etc can all > contain breaking changes until we feel comfortable declaring a particular > release the new long-term API stable release at some point in the future. > Off-list there have been mentions of trying to do quarterly releases, and > in that case it might be reasonable to mark one release per year as the new > long-term stable. We need to decide on that. > > I'm sure others will come forward with additional pull requests, but if we > do decide to use a more relaxed approach to versioning and breaking changes > (in some way), then I don't think 5.0 need to contain much more than that > mentioned above. Better instead to release it after only a few months > perhaps. > > > /Oskar > > -- > > --- > You received this message because you are subscribed to the Google Groups > "nhibernate-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > > > -- > Sem mais, > Edno. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "nhibernate-development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
