On Sun, Jul 27, 2014 at 1:09 PM, Oliver Lietz <[email protected]> wrote:
> On Wednesday 23 July 2014 08:04:00 Carsten Ziegeler wrote:
>> 2014-07-22 23:12 GMT+02:00 Oliver Lietz <[email protected]>:
>> > > +1, I think it's important to have a Sling 7 release soon.
>> >
>> > Yes, but not a half-baked one. We would have even more users complainig
>> > about
>> > 7 as we now have with 6.
>>
>> Well, which part do you think would be half-baked if we simply release
>> everything as is. I think most of the bundles (if not all) are in a pretty
>> good shape right now.
>
> Sorry if it sounded to harsh. Some points which come to my mind:
> - we don't have full support for Java 8

I looked in Jira for related issues but found nothing [1] . What are
we missing for Java 8?

> - SLING-3575 failing test with newer Jackrabbit

It would be good if you added more details about the test failure to
the issue. This would allow others beside the issue reporter to chime
in and maybe propose a fix.

> - the versions of Commons Threads for the Event bundle used at compile and
> runtime are not compatible

I'm not sure what the problem is here. In
launchpad/builder/src/main/bundles/list.xml I see

        <bundle>
            <groupId>org.apache.sling</groupId>
            <artifactId>org.apache.sling.commons.threads</artifactId>
            <version>3.2.0</version>
        </bundle>

        <bundle>
            <groupId>org.apache.sling</groupId>
            <artifactId>org.apache.sling.event</artifactId>
            <version>3.3.10</version>
        </bundle>

And in bundles/extensions/event/pom.xml

        <dependency>
            <groupId>org.apache.sling</groupId>
            <artifactId>org.apache.sling.commons.threads</artifactId>
            <version>3.1.0</version>
            <scope>provided</scope>
        </dependency>

I don't see any incompatibilities in there. In any case, if you see
problems related to that setup please file a Jira with an explanation
so that it's not forgotten in this email thread.

> - SLING-3008 looks still problematic

Is the issue that we have a code block that can be removed? I don't
see that as a launchpad release blocker.

> - lack of documentation, major changes between 6 and 7, upgrade paths

That sounds like a general issue that I agree with. But then again,
not releasing while waiting for documentation is not bringing any
value IMO. What's important is that we get a release which supports
non-ancient Java versions out for developers to try out. We can talk
later when we have people complaining about upgrade paths :-) .

In my (limited) experience, people build their own bundle lists
anyway, the launchpad is just a way to quickly get one's hands dirty
with Sling.

> - Oak integration not on par with Jackrabbit (failing tests)

Right, at the moment we have two failing ITs for Oak ( [2] ). However,
we can simply release with Jackrabbit as the default runmode, and look
into those later.

> I don't see any real value in releasing a *major* 7 now "as is" and then plan
> any future releases and how to improve the release process. If it takes even
> more time to get a major release out which can be used as good basis for
> future releases than so it be even if it takes more weeks or months.
>
> If the effort for releasing major versions is to high we should maybe switch
> to a rolling release model where we maintain a list with released and
> compatible bundles.

We can discuss that for Launchpad 8 or 7.1 or 2014.1 or whatever we
decide to call it. But I think it's important to get version 7 out as
soon as we can.

Thanks,

Robert

[1]: 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SLING%20AND%20text%20~%20%22java%208%22%20and%20resolution%20is%20empty
[2]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-oak-it-1.6/

>
> Regards,
> O.
>
>> Carsten
>>
>> > >> I haven't checked the SNAPSHOT bundles, but I think there are some
>> >
>> > bundles
>> >
>> > >> where nothing changed after their latest release so we may use some
>> > >> already released bundles and not release *all* now.
>> >
>> > there are probaly less than 20 bundles.
>>
>> In theory, the list.xml should only reference snapshots which have actually
>> changes. But I'll check this today to see where we are.
>>
>> Carsten

Reply via email to