I've done my final test rounds for the php release, and everything checks out perfectly.
Release are go! On Tue, Apr 21, 2009 at 7:02 PM, Ian Boston <i...@tfd.co.uk> wrote: > The 1.0 release will come from the branch at > http://svn.apache.org/repos/asf/incubator/shindig/branches/1.0.x-incubating/ > > When its cut, there will be a tag, the final details are being sorted out. > Ian > > > On 21 Apr 2009, at 01:49, Carmen Sarlo wrote: > > How can I check out the 1.0 release? Is there a new branch cut? Do I have >> to >> check out up to a certin rev? >> >> >> >> Carmen >> >> >> On Sat, Apr 18, 2009 at 6:53 AM, Santiago Gala <santiago.g...@gmail.com >> >wrote: >> >> El mié, 15-04-2009 a las 15:57 +0200, Chris Chabot escribió: >>> >>>> On Wed, Apr 15, 2009 at 3:28 PM, Vincent Siveton >>>> <vincent.sive...@gmail.com>wrote: >>>> >>>> 2009/4/15 Chris Chabot <chab...@google.com>: >>>>> >>>>>> I spoke yesterday with Chris about the make-release.sh: this script >>>>>>> won't work on my ubuntu box :( >>>>>>> >>>>>> >>>>>> >>>>>> Vincent I thought the fix was simple enough: >>>>>> >>>>> >>>>> Yes yes the fix was working perfectly :) >>>>> >>>>> Saying that "it won't work on ubuntu" is a slight over-exaggeration >>>>>> >>>>> in my >>> >>>> opinion :) >>>>>> >>>>> >>>>> Sorry if I offend you, my point was that the out-of-box script needs >>>>> to be changed depending the platform used for the compilation. >>>>> >>>>> >>>> No worries, no offense of any kind is involved! I'm merely trying to say >>>> that a sh shell is by far more pervasive then a java & maven combo, >>>> >>> perhaps >>> >>>> I should've framed that differently :) >>>> >>>> The problem is that 'bash' isn't defined by the FHS (Filesystem >>>> Hierarchy >>>> Standard) on linux, the solution is to, instead of depending on a fixed >>>> >>> path >>> >>>> (#!/bin/bash), I should either a) change it to #!`which bash`, which >>>> will >>>> expand to the location of bash, or b) change the script to use >>>> #!/bin/sh, >>>> which is present on pretty much any *nix platform we care about (*bsd, >>>> linux, mac, solaris, etc); So I'm likely to pick option b here. >>>> >>>> >>> In my ubuntu boxes bash is in /bin/bash, as it should. :) I'm not sure >>> what the problem was. If it was the ubuntu-server flavor, it is quite >>> minimalistic as it installs (not even python, for instance), so it might >>> have been missing bash, and having other shell. >>> >>> However sh will be installed on pretty much anywhere (except for win, >>>> >>> who'd >>> >>>> have to install cygwin) and the same can't be said for java and maven, >>>> >>> which >>> >>>> won't be present on most of the boxes that will be running >>>> >>> php-shindig.... >>> >>>> after all, if they had a complete java stack and maven installed that >>>> >>> would >>> >>>> imply their likely a java shop and they would thus more likely be using >>>> java-shindig :) >>>> >>>> >>> ubuntu needs frequently wiping of the java packages and install of the >>> sun jdk for some applications to run correctly, in my experience. I lost >>> some time fighting against openjdk and icedtea recently to be forced to >>> install sun-java6-jdk finally to run some legacy java apps. >>> >>> Regards >>> Santiago >>> >>> >>>> (i did make a mental note I should probably use /bin/sh though since >>>>>> according to the FHS that should always be available, but i'll have >>>>>> >>>>> to >>> >>>> validate that the script works the same on sh first before i can >>>>>> >>>>> switch >>> >>>> that >>>>> >>>>>> over) >>>>>> >>>>>> Using Maven will be more platform independent, but Chris underlines >>>>>> >>>>> me >>> >>>> that the Maven assembly generates a different layout than the >>>>>>> make-release.sh. >>>>>>> So I modified the Maven files in r765148 to be align with this >>>>>>> >>>>>> script. >>> >>>> >>>>>>> @Chris, could you review the generated and confirm that it is the >>>>>>> >>>>>> wanted >>> >>>> layout? >>>>>>> >>>>>>> >>>>>> >>>>>> I also commented that I think this is a "When you have a hammer, >>>>>> >>>>> everything >>>>> >>>>>> looks like a nail" type of solution. >>>>>> >>>>>> Most people who use PHP probably won't have a lot of java and maven >>>>>> knowledge, and are even likely not to even have a working java binary >>>>>> installed, let alone feeling like installing maven and downloading >>>>>> >>>>> many >>> >>>> Mb's >>>>> >>>>>> of dependencies and we really shouldn't force that down people's >>>>>> >>>>> throats, >>> >>>> not if those tens of megabytes, and different-environment >>>>>> >>>>> dependencies >>> >>>> are >>>>> >>>>>> just to solve something that can also be done with 20 lines of shell >>>>>> >>>>> script. >>>>> >>>>>> That just sounds like a solution looking for a problem :) >>>>>> >>>>>> Keep in mind that this script could be used to create a >>>>>> >>>>> release-type-layout >>>>> >>>>>> of the directory structure and configuration files by anyone who uses >>>>>> php-shindig, so the usage of it is far wider then just once to >>>>>> >>>>> generate a >>> >>>> release tarbal, as such the whole java / mvn dep could only be worth >>>>>> >>>>> it >>> >>>> from >>>>> >>>>>> a php perspective if it offered significant benefits over shell >>>>>> >>>>> script >>> >>>> (or >>>>> >>>>>> even php based) one.. >>>>>> >>>>> >>>>> I guess only Shindig devs could use this script to make a release and >>>>> (I hope) everybody here has a minimum knowledge of java/maven :) >>>>> If someone want to make a fork of PHP Shindig, he will probably create >>>>> its own script to make its release. >>>>> >>>>> The script file works perfectly but it is platform dependent which is >>>>> IMHO bad. >>>>> >>>> >>>> >>>> I can't agree with that argumentation. the sh shell is part of *every* >>>> >>> unix >>> >>>> like instalation, where as maven is something people will have to >>>> >>> download >>> >>>> the correct latest version of and install by hand; The statement that a >>>> shell script using sh is platform dependent goes against decades of >>>> >>> history >>> >>>> (sh has been a standard part and default shell of most unix systems >>>> since >>>> it's inception in 1977) >>>> >>>> The only thing that somehow gave you that impression is that ubuntu (and >>>> probably debian too by extend) have their bash shell in the /usr/bin >>>> dir, >>>> and not in /bin... thats the *only* thing, and that can very easily be >>>> >>> fixed >>> >>>> by using either `which bash` or using sh instead of bash. >>>> >>>> The nice thing of having a standard script is that if some OSS project >>>> includes php-shindig (which quite a few do already), they can use that >>>> standard script to wrangle the svn checkout to a standard layout that >>>> >>> they >>> >>>> can include (and without the whole java tree). Depending on java + maven >>>> >>> is >>> >>>> as un-natural to them as using a PHP tool for java packaging would be :) >>>> >>>> >>>> >>>> We need 2 release managers to create artifacts, and I dont >>>>> think it is the way to go. >>>>> If Maven is too bigger, WDYT to use ant? It will be easy to integrate >>>>> it in the release process. >>>>> >>>> >>>> >>>> I think the whole premise of using a java packaging tool for php is akin >>>> >>> to >>> >>>> the hammer -> nail analogy... I see no problems with a release manager >>>> running one shell script to create the php-shindig tar&zip archives, and >>>> >>> I >>> >>>> think most everybody here would be comfortable with that, right? >>>> >>>> >>>> Do we want to centralize build under Maven, for all languages >>>>> supported and for making release? >>>>> >>>>> >>>> Pros: >>>> 1) Unified release procedure for both languages >>>> (I'm not including 'platform independence here, since to me introducing >>>> java+maven deps into the php world is a much bigger restriction then >>>> depending on the sh shell) >>>> >>>> Cons: >>>> 1) Unmaintainable by the php dev's >>>> 2) Un-usable for 3rd party projects who don't have java/maven/etc but >>>> >>> want >>> >>>> to do svn snapshots >>>> 3) Using an overly complex solution for something that has a simple >>>> >>> solution >>> >>>> available already >>>> >>>> So far based on the above +/- list my preference so far is to use the >>>> >>> shell >>> >>>> script >>>> >>> >>> >>> >
