Ok doing the branch now.
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
