So it seems like the strategy for now would be to generally just use the
latest build. The question going forward is how to avoid cases where you
decide to rewrite some part or make other significant changes. Obviously as
the developers of the library, you have the most knowledge of when that is
happening. For an outsider, without reading and understanding all the
changes, it's hard to know if there is "potential danger" lurking.
Patrick Earl
On Wed, Dec 8, 2010 at 12:22 PM, Wenig, Stefan <[email protected]>wrote:
> from relinq.codeplex.com:
>
>
>
> Releases are available for download from CodePlex. Weekly builds are
> available in source code and binary form at
> http://www.re-motion.org/builds. Note that due to the goodness of TDD,
> weekly builds are generally considered stable and we do often use those in
> production. However, if you need a bug fix you will have to upgrade to a
> newer version. Hotfixes are only produced for release versions (even/odd
> scheme: release versions have even minor version numbers, such as the
> upcoming 1.14.0, and hotfixes will be numbered 1.14.1, 1.14.2 etc.).
>
> It's all in the unit tests. We're not doing any additional testing for
> releases, they just differ in the versioning scheme and support strategy. So
> in theory, with a weekly you could run into a situation where you'd need a
> hotfix, but find you have to upgrade to the newest weekly, with tons of
> breaking changes. But that's really just theory. The re-linq front-end is
> very stable right now, we're just adding tiny bug fixes or features as they
> are requested.
>
>
>
> HTH,
>
> Stefan
> ------------------------------
> *From:* [email protected] [
> [email protected]] on behalf of Patrick Earl [
> [email protected]]
> *Sent:* Tuesday, December 07, 2010 18:37
>
> *To:* [email protected]
> *Subject:* Re: [nhibernate-development] Fwd: NHibernate 3 GA, Linq and
> VB.NET
>
> While I don't want to aggravate this heated argument, it is a bit odd
> that re-linq has releases that aren't actually the intended releases. Is
> every single build a valid release? If not, how are external users to know
> which code is stable and ready for external consumption?
>
> Patrick Earl
>
