Sounds good to me. So now the next step is to do the branch and produce the tarball so we all can bang on it?
-Dan On Thu, Nov 20, 2008 at 2:16 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > Ok so... > > Proposing > Branch shindig to > branches/0.8.1-x with a version of 0.8.1-1-SNAPSHOT > increment trunk version to 0.9-1-SNAPSHOT indicating 0.9-1 will be the > next release > > The first tag from 0.8.1-x > will be 0.8.1-1 > at which point the branch version will got to 0.8.1-2-SNAPSHOT > > and at sometime trunk will branch again to > branches/0.9-x with a version of 0.9-1-SNAPSHOT > > Did I get that right :) > > Ian > > > On 20 Nov 2008, at 13:09, Dan Peterson 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >
