On Oct 10, 2008, at 2:12 AM, James Strachan wrote:
> > 2008/10/10 [EMAIL PROTECTED] <[EMAIL PROTECTED]>: >> >> Internally we're able to use something newer >> than 1.0 because we're willing to cope with >> incompatible API changes. This is a lot of >> work, but we bear it to get access to features >> that are still under development. > > I'm sure lots of folks outside of Google would also be happy to cope > with incompatible API changes too :) > > How about doing a 2.0-alpha / 2.0-beta release with a warning that > things may change before 2.0 final? Folks in OSS land really dont mind > if things change; provided releases are named such that folks know its > not *the* stable 2.0 release. Just as another quick note, some dependency management tools will even support the levels of "snapshot" releases in this order: alpha beta milestone release candidate Savant for example will also support numbers after those and figure out how to select the correct version based on that. For most of my projects I begin with alpha and work up like this: jcatapult-core-1.0-A1 jcatapult-core-1.0-A2 jcatapult-core-1.0-B1 jcatapult-core-1.0-B2 jcatapult-core-1.0-M1 jcatapult-core-1.0-M2 jcatapult-core-1.0-RC1 ... Works nicely and once 1.0 is released it will upgrade to that regardless of transitive dependencies and such. -bp --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
