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 <[email protected]
>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
<[email protected]>wrote:
2009/4/15 Chris Chabot <[email protected]>:
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
