Bit of a problem with hanging tests that made me stumble on the finish line. Anyway, I've merged a few things today, and cleared out the remaining tasks from Jira by moving them to 5.0.
Waiting for PR 513 and 531 to build/test so we can merge those, then I'll make a new attempt at releasing 4.1CR1 - unless someone beats me to it, it's going to be at least 12 hours until I'll get back to this. /Oskar 2016-11-19 23:32 GMT+00:00 Oskar Berggren <[email protected]>: > I'll look into putting out rc1 Sunday evening (UTC). > > 2016-11-16 6:06 GMT+00:00 Alexander Zaytsev <[email protected]>: > >> I think we shall release 4.1 release candidate immediately. However there >> are some pull requests which are worth merging prior 4.1. >> >> Best Regards, >> Alexander >> On Sat, 12 Nov 2016 at 6:04 AM, Oskar Berggren <[email protected]> >> wrote: >> >>> Is there anything preventing us from doing a 4.1 release candidate >>> immediately? >>> >>> >>> Going forward, I wonder if we should switch to a more flexible approach >>> regarding releases. I sort of like what the GTK project did recently, >>> namely that the first set of minor releases in each major release would NOT >>> promise API stability. >>> >>> In NH terms this could mean that: >>> >>> NH 4.0.x releases with no API changes. >>> >>> NH 4.1.x contains API additions but no API breaks (same as current >>> scheme) >>> >>> NH 5.0 may (and will) contain API breakage. >>> >>> NH 5.1 may also break API >>> >>> NH 5.2 may also break API >>> >>> ... >>> >>> NH 5.something will eventually be declared new API stable version. Most >>> likely NH6 branch will open immediately as the new non API-stable branch. >>> >>> NH 5.something+1 must be API compatible with previous version. >>> >>> >>> >>> The benefit of this would be that API-breaking patches can more quickly >>> be accepted into a release, without waiting in the sidelines for a year or >>> two. User's can either elect to use the latest version, in which case they >>> must be prepared to handle API changes more frequently, or stay on an >>> API-stable branch until the next API-stable branch is declared. >>> >>> >>> This would no longer be strict "semantic versioning", but I'm not sure >>> we should care too much about that. >>> >>> >>> /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. >>> >> -- >> >> --- >> 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.
