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 -~----------~----~----~----~------~----~------~--~---
