Shindig-0.8-<release#> sounds good to me. As far as the analogy goes, lets indeed not dive to deeply into it since I don't have a better solution either; My first reaction was to think of what's common in the opensource world, and I can't think of any practical examples where a project release # correlates to a spec number, but I guess we're in a special situation here :)
Creating a branch in svn is simple, and php-shindig doesn't have internal version numbers that need to be updated (so feel free to do a straight svn copy), but as far as i understand there is some signing / versioning to do on the java side of things? If so it's prob best left to someone with mvn versioning / singing experience :) -- Chris On Thu, Nov 20, 2008 at 10:09 PM, Dan Peterson <[EMAIL PROTECTED]> wrote: > On Thu, Nov 20, 2008 at 12:55 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > >> ps we could also go for an iteration release number in the format of >> >> shindig-0.8.1-22 >> >> (where 22 would be the 22nd release that supports the 0.8.1 spec >> completely), but then we have no way to communicate things like 'this >> version changes the internal API' > > > Yes, this is similar to what Kevin and I agreed to earlier on this thread. > > I think it is quite likely we'll have at least one release for each spec > version in the future, and we can use a.b.FOO, where a.b is the spec version > and FOO is effectively a counter of the "stable build" > > This would mean we'd be working on a release for Shindig 0.8. > > So I think we either should break the correlation between the spec and >> shindig release numbers (after all it implements the specs, but isn't the >> spec right? Just like firefox 3 implements http 1.1 :and there's no >> correlation between the 2)), or we should change shindig's development model >> and think about how to sync spec versions with shindig internals / >> experiments. >> > > I don't want to go deep on this analogy since we're converging, but > certainly Firefox does more than simply implement the HTTP spec. > > -Dan > > >> On Thu, Nov 20, 2008 at 9:45 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: >> >>> plus trying to keep the versions synced can also lead to lots of >>> confusion >>> >>> If we implement 0.8.1 completely (shindig version 0.8 ?), then add some >>> previews of 0.9 functionality (proxied content) is the shindig version 0.8 >>> or 0.9 or 0.8.1? >>> >>> And if we fix some bug fixes would the next version be 0.8.2 ? And would >>> that make people believe there is a 0.8.2 version of the spec? :) >>> >>> I guess going for a double release number *could* work, ie something like >>> shindig-1.0.0-0.8.1, but i'm not sure if that's very 'pretty' >>> >>> To be honest, I would be happy to go for a 1.0.0, and depend on the docs >>> + site (which we REALLY should address some day, things like: change logs, >>> docs, blog, info, etc) to communicate which version supports what >>> >>> >>> On Thu, Nov 20, 2008 at 9:23 PM, Dan Peterson <[EMAIL PROTECTED]>wrote: >>> >>>> On Thu, Nov 20, 2008 at 12:09 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: >>>> >>>> > On Thu, Nov 20, 2008 at 11:35 AM, Tim Moore <[EMAIL PROTECTED]> >>>> wrote: >>>> > >>>> > > I'll chime in and mention that several people that I've talked to >>>> have >>>> > been >>>> > > confused about this. I think it would be great if the Shindig >>>> release >>>> > > version were to match the latest spec version that it fully >>>> implements. >>>> > >>>> > >>>> > The architectural version can match (opensocial-0.x == >>>> > shindig-0.[yyyy.zzzz]), but Shindig will never match the opensocial >>>> version >>>> > exactly. If I change a major interface in the code, we're still >>>> > implementing >>>> > the same opensocial version but we can not continue using the same >>>> version >>>> > number. >>>> > >>>> >>>> This sounds reasonable to me. >>>> >>>> -Dan >>>> >>>> > On Nov 20, 2008, at 11:10 AM, Dan Peterson wrote: >>>> > > >>>> > > Hey folks, >>>> > >> >>>> > >> I am really excited that we're getting to an OpenSocial v0.8 (well, >>>> > 0.8.1) >>>> > >> compliant release. I think we'll learn a lot about making Shindig a >>>> > great >>>> > >> piece of infrastructure through these releases. >>>> > >> >>>> > >> To Ian's question, I think we should be careful about the version >>>> > number: >>>> > >> it >>>> > >> seems confusing if we have OpenSocial at v0.8, but Shindig at v1.0. >>>> > >> Shindig's mission/scope is to implement the OpenSocial spec, so >>>> it's >>>> > >> awkward >>>> > >> to have different numbering systems for the releases of the >>>> > >> implementation. >>>> > >> I certainly realize that versions are just arbitrary numbers, but >>>> > sending >>>> > >> the message that Shindig is at 1.0 is over-promising with regards >>>> to >>>> > >> potentially breaking changes and stability, given the state of the >>>> > >> "underlying" spec. >>>> > >> >>>> > >> My thought was that this would be a release of Shindig v0.8. >>>> > >> >>>> > >> -Dan >>>> > >> >>>> > >> On Thu, Nov 20, 2008 at 6:25 AM, Ian Boston <[EMAIL PROTECTED]> wrote: >>>> > >> >>>> > >> I don't expect this to be controversial, but I should as just for >>>> > >>> process. >>>> > >>> >>>> > >>> Proposing >>>> > >>> Branch shindig to >>>> > >>> branches/1.0.x with a version of 1-SNAPSHOT >>>> > >>> increment trunk version to 1.1-SNAPSHOT indicating 1.1 will be the >>>> next >>>> > >>> release. >>>> > >>> >>>> > >>> The version numbers are more for Java than for Php, but I guess >>>> there >>>> > >>> might >>>> > >>> be a version number in the php code ? >>>> > >>> >>>> > >>> I have done a dry run of the maven release plugin and there are no >>>> > >>> issues, >>>> > >>> so it should be a simple one command process. (it also branches >>>> the php >>>> > >>> code >>>> > >>> because we left a pom in the base directory) >>>> > >>> >>>> > >>> Any comments ? >>>> > >>> Happy with the version numbers ? >>>> > >>> >>>> > >>> Ian >>>> > >>> >>>> > >>> >>>> > >>> >>>> > > -- >>>> > > Tim Moore >>>> > > Atlassian Plugin Developer >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >>>> >>> >>> >> >
