Doing 4.1CR1 now. 2016-11-20 23:29 GMT+00:00 Oskar Berggren <[email protected]>:
> 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.
