Ok, step one seems to be completed, lets go plan for our step 2 ... going to actual release tarbals :)
I've got 1 or 2 minor fixes left to do, and I'll make sure that the release branch is kept up to date with trunk for the fixes ... But we also need someone to do the same for the java / javascript side of things (I've seen a fair amount of commits landing on trunk which seemed to be bug fixes, without counterparts on the release branch). After we make sure that's properly synced up, lets plan a data for pushing out the tar.gz's and lets get brainstorming about a release announcement to post on the shindig site together with the (unofficial / incubating) release. On Fri, Nov 21, 2008 at 2:29 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > Ok the release artifacts are now at > http://people.apache.org/~ieb/shindigmaven/<http://people.apache.org/%7Eieb/shindigmaven/> > > This is a maven 2 repo for the branch with snapshots. > > I have sym linked the php release artifacts into the root directory, but > the java version is from the repo. > > We could build binary and source distros for the java version without too > much effort. > > None of this is signed. > > Ian > > On 20 Nov 2008, at 16:38, Dan Peterson wrote: > > 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >
