I have just committed a fix to the assembly that generates complete
source zips.
There still needs to be a fix to the tarball generation. but that
should give
tarball of the source
tarball of the php application ready for install
all java artifacts ready to go into a maven repo.
Ian
I will be offline until this evening. (Sydney time)
On 23 Nov 2008, at 20:35, Chris Chabot wrote:
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
