VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]

[Carsten Ziegeler <cz...@apache.org>]

Ok,

so I cancel this vote due to mainly two problems:
a) a bug (SLING-512) which will be solved by Felix :)
b) the source release should rather be one big archive

The plan for release is as follows:
a) We will fix the bugs in the affected modules and then tag them as 
2.0.2 bundles/modules.
b) We will remove the 2.0.0 tags from svn for the modules from a)

c) The source release
I will create a tag in svn (sling-2.0.0-incubator-release - we can use a 
different name) which gets the same layout as our svn trunk, but with 
all modules removed that we don't want to have in the release. Instead 
of copying everything we will use svn externals to point from this tree 
to the various tags of the bundles. This gives us both: a big source 
tree of everything and single tags for each bundle.

d) We will release the source archive from c) and binaries only for the 
launchpad app and launchpad webapp. In addition we will provide all 
maven artifacts. I'll build all these from the tag created in c)

e) All upcoming releases will be single bundle releases.

I hope this is ok for everyone?

Carsten

Bertrand Delacretaz wrote:
> On Wed, Jun 4, 2008 at 7:51 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> 
>> org.apache.sling.launchpad.app-2.0.0-incubator
> ...
>> org.apache.sling.launchpad.webapp-2.0.0-incubator...
> 
> Are broken due to SLING-512, which apparently hides a slightly more
> serious problem.
> 
> -Bertrand
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote:
> On Thu, Jun 5, 2008 at 11:41 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ... e) All upcoming releases will be single bundle releases....
> 
> I think Jukka has valid points here, but we don't need to decide on
> this right now.
> 
>> ... I hope this is ok for everyone?...
> Ok for me, thanks.
> 
> At some point we can maybe add an OBR + XSLT file like the one at
> http://oscar-osgi.sourceforge.net/obr-repo/releases.xml to point to
> our Maven artifacts, if people want do download them without using
> Maven.
> 
Felix and I have discussed this offline :( , but yes, we'll provide such
a file - there is a maven plugin which generates it for us; we just have 
to figur out how this will work in our scenario.... :)

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]

[Bertrand Delacretaz <bd...@apache.org>]

On Thu, Jun 5, 2008 at 11:41 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>
>... e) All upcoming releases will be single bundle releases....

I think Jukka has valid points here, but we don't need to decide on
this right now.

>... I hope this is ok for everyone?...
Ok for me, thanks.

At some point we can maybe add an OBR + XSLT file like the one at
http://oscar-osgi.sourceforge.net/obr-repo/releases.xml to point to
our Maven artifacts, if people want do download them without using
Maven.

-Bertrand

Re: VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Jun 5, 2008 at 12:41 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> I hope this is ok for everyone?

OK, with one concern:

> e) All upcoming releases will be single bundle releases.

I'm a bit worried about this. Even though Sling consists of multiple
components, from the end user perspective it's still a single product,
and it would be good if that was at least somehow reflected in our
releases.

For example, how do we identify the Sling version that is deployed
somewhere? The collection of the versions of all the deployed bundles?
Where and how can I find all the Sling source code that went in to
that deployement? I'd rather not have to trace down the entire
dependency tree to find all the relevant source packages.

One could argue that all the required information is in the Maven
repository and there is already good tooling to manage that
information, but I'm still somewhat hesitant to rely on the repository
so much. Perhaps I'm just being old-fashioned and this won't matter in
practice, but I still feel we're loosing something valuable here.

At least this is another good example of how Maven and the Maven
repository are taking a much more essential role (i.e. not just
another build tool) in release management and even changing the
meaning of a "release". It'll be interesting to see where such
progress takes us and how well for example the Apache release
practices will cope with this change. :-)

BR,

Jukka Zitting

Re: VOTE CANCELLED [was Re: [VOTE] Release Sling Artifacts]

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Donnerstag, den 05.06.2008, 11:41 +0200 schrieb Carsten Ziegeler:
> Ok,
> 
> so I cancel this vote due to mainly two problems:
> a) a bug (SLING-512) which will be solved by Felix :)
> b) the source release should rather be one big archive
> 
> The plan for release is as follows:
> a) We will fix the bugs in the affected modules and then tag them as 
> 2.0.2 bundles/modules.
> b) We will remove the 2.0.0 tags from svn for the modules from a)
> 
> c) The source release
> I will create a tag in svn (sling-2.0.0-incubator-release - we can use a 
> different name) which gets the same layout as our svn trunk, but with 
> all modules removed that we don't want to have in the release. Instead 
> of copying everything we will use svn externals to point from this tree 
> to the various tags of the bundles. This gives us both: a big source 
> tree of everything and single tags for each bundle.
> 
> d) We will release the source archive from c) and binaries only for the 
> launchpad app and launchpad webapp. In addition we will provide all 
> maven artifacts. I'll build all these from the tag created in c)
> 
> e) All upcoming releases will be single bundle releases.
> 
> I hope this is ok for everyone?

+1

Regards
Felix