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 nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
