2013/3/12 Dmitry Naumov <[email protected]>: > Let's take NH-3417 as example. This is yet another bug related to LINQ and > OData support. Let's imagine there are issues already fixed in 3.3.3.CR1 > someone eagerly waits for and these issues have no connection with LINQ or > OData. Now we have two options: either wait a bit more trying to fix NH-3417 > and hope no more issues arise or, taking into account there are other > important fixed issues, release 3.3.3 as is.
But the same could be said for any small fix in any part of the code. We have already had the principle that a minor release should have no breaking changes. and I've tried to reduce the impact of a minor release further, by keeping the assembly version constant. > > Let's look around on trends. Even Microsoft spin all the ASP.NET stuff out > of VS release cycle. They want to release twice a year with pre-official > releases available even more frequently. "Time to developer" for code is the > same important metric as "time to market" for product. The VS release cycle is 2-3 years. While things with NHibernate sometimes take longer than I would prefer, we do still release several times per year. I would still prefer to release the entire project more often. If we can get to a point were we release every second month (or so) (or even every month perhaps), there also isn't that much of a problem if a particular fix doesn't make it for a particular release. The delay with 3.3.3 is caused by an unfortunate breaking change which we have no decision on how to handle yet. I would prefer if there are no more changes except resolving this, to avoid further delays. /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/groups/opt_out.
