I'd say for commercial software it's more like 98% marketing and 2% engineering. Take the hilarious jump BEA did back in the day from 4 to 7. That was classic. Commercial software is about customers feeling warm and fuzzy. A few companies have even gone so far as to skip majors and only release minors (i.e. releasing 8.1 first rather than 8.0) because people think majors are "buggy". I love marketeers!
-bp On Oct 10, 2008, at 1:39 PM, Robbie Vanbrabant wrote: > I agree with Bob here. I'd even say that the version of any third > party software you use is 30% about marketing, 30% about common > sense 40% about a versioning scheme. A dependency manager can > probably get to the common sense or versioning scheme, but you will > never beat marketing. :-) > > Cheers > Robbie > > On Fri, Oct 10, 2008 at 9:17 PM, Brian Pontarelli <[EMAIL PROTECTED] > > wrote: > > While this is somewhat true, it doesn't preclude tools for managing > compatibility on version numbers as long as it supports different > schemes. Savant for example supports, major, minor and patch > compatibility as well as custom built solutions. The key is that a > project has to pick a versioning scheme and stick to it. If Guice > wants to be compatible between 1 and 2 and NOT 3, then version 1 and > 2 are "major compatible" while version 3 is "minor" compatible and > Savant can still figure it out. > > Forcing tools and builds to manage every projects compatibility > rules for every version is not only annoying, but tedious and often > error prone and wrong. This is one of the reasons some tools just > grab the latest version and don't check compatibility. They don't > want to bother with managing reams of compatibility information. > Savant specifically doesn't do this, but it also doesn't go for the > custom DSL for crazy ad hoc compatibility and naming either. > > Okay, enough DM ranting. I'll just say that Guice should pick a DM > scheme and stick to it. I personally really don't like this 1 and 2 > are compatible but 3 isn't stuff. I'd much rather see the next > release named 1.1 or 1.2 if it is compatible or just calling it not > compatible and have a little more freedom with the APIs. Either way > works for me. But that's just from coming from a strict DM guy. > > -bp > > > On Oct 10, 2008, at 12:20 PM, Bob Lee wrote: > >> When it comes to versioning schemes, the only thing you can count >> on is that no two projects will use exactly the same conventions. >> Any tool that cares about whether two versions are compatible >> should rely on explicit meta data, not numbering/naming conventions. >> >> As for releasing often, we release code every time we check in. >> Many people already build Guice themselves and test out the latest >> features. If we decide that Guice needs some sort of pre-release >> release before 2.0, we'll do it, but right now, I don't think we'll >> need one. >> >> Bob >> >> On Fri, Oct 10, 2008 at 3:15 AM, Endre Stølsvik >> <[EMAIL PROTECTED]> wrote: >> And, as Gili states, "2.0" by itself markedly states that there are >> major, incompatible API changes. My personal understanding of the OSS >> world versioning scheme is rather like Gili's, apparently, where only >> revisions (the 0.0.x) don't have any API changes. And, as James here >> mentions, you also have the alpha, beta, rc nomenclature to ride on. >> >> On Gili's mail, I do not agree with him that it at this point is okay >> to "take your time". Get something out - it's been way over a year. >> There this saying: "Release early, release often". That's my >> understanding of open source, and that at least seems like how you >> get >> community building, involvement, input and innovation. >> Knowing that you've *obviously* read it, here's just for quick >> context >> reference: >> >> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html >> >> Don't end up as The Google Cathedral! :-) >> >> IMHO blahblah, of course. >> >> Endre. >> >> >> >> >> >> > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
