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<http://www.catb.org/%7Eesr/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 -~----------~----~----~----~------~----~------~--~---
