Towards Sling 6

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

Hi all,

I have started listing and checking bundles included in the current
Launchpad Builder in our Wiki at [1].

This shows that we have quite a number of bundle releases to cut and
vote on.

I think for each bundle we should check for a few things:

  * Open issues to be still fixed (or not)
  * Validate version of package exports
  * Validate package import versions (most importantly
      version ranges for implemented API)

Any opinions on how to proceed ? Do we split responsibility for checks
and/or release cutting ?

I will pursue the Apache Felix related releases in the Apache Felix
projects.

Thanks and Regards
Felix

[1] https://cwiki.apache.org/SLING/towards-sling-6.html

Re: Towards Sling 6

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

Hi,

On 30.07.2010 20:43, Justin Edelson wrote:
> Thanks for putting this together. A few thoughts:
> * if we're going to upgrade 3rd party dependencies, let's do that sooner
> than later so they have the maximum burn-in time before the release

Makes sense. See SLING-1623

> * personally, I'd prefer we keep tika and derby to the versions used in
> jackrabbit just to stay on the safe side.

I cannot tell for Derby (though they have a CVE fixed in the 10.6.1.0
version).

As for Tika: I think it is a save (and good) call to upgrade to the
latest Tika version. Particulary with respect to some dependent
libraries used by Tika.

> * I think formauth should be included in the bundle list.

Done. See SLING-1622. Thanks for the reminder.

> * scripting.api does not need a release. the change made in SLING-1510
> ONLY impacted scripting.core (originally this was not the case, but it
> was in the second implementation)

Fine. So we keep that. One release less to cut ;-)

> 
> BTW, I would highly recommend using JIRA Client for analyzing open issue
> per component/version.

Yes, I will add JIRA version queries to the Sling bundles to be
released. Thus we can easily tell what open issues there are.

This would of course require use to scan issues and target them as
appropriate. I will start giving it a shot; others are encouraged to
chime in.

Regards
Felix

> 
> Justin
> 
> On 7/30/10 1:57 PM, Felix Meschberger wrote:
>> Hi all,
>>
>> I have started listing and checking bundles included in the current
>> Launchpad Builder in our Wiki at [1].
>>
>> This shows that we have quite a number of bundle releases to cut and
>> vote on.
>>
>> I think for each bundle we should check for a few things:
>>
>>   * Open issues to be still fixed (or not)
>>   * Validate version of package exports
>>   * Validate package import versions (most importantly
>>       version ranges for implemented API)
>>
>> Any opinions on how to proceed ? Do we split responsibility for checks
>> and/or release cutting ?
>>
>> I will pursue the Apache Felix related releases in the Apache Felix
>> projects.
>>
>> Thanks and Regards
>> Felix
>>
>> [1] https://cwiki.apache.org/SLING/towards-sling-6.html
> 
> 

Re: Towards Sling 6

[Justin Edelson <ju...@gmail.com>]

Thanks for putting this together. A few thoughts:
* if we're going to upgrade 3rd party dependencies, let's do that sooner
than later so they have the maximum burn-in time before the release
* personally, I'd prefer we keep tika and derby to the versions used in
jackrabbit just to stay on the safe side.
* I think formauth should be included in the bundle list.
* scripting.api does not need a release. the change made in SLING-1510
ONLY impacted scripting.core (originally this was not the case, but it
was in the second implementation)

BTW, I would highly recommend using JIRA Client for analyzing open issue
per component/version.

Justin

On 7/30/10 1:57 PM, Felix Meschberger wrote:
> Hi all,
> 
> I have started listing and checking bundles included in the current
> Launchpad Builder in our Wiki at [1].
> 
> This shows that we have quite a number of bundle releases to cut and
> vote on.
> 
> I think for each bundle we should check for a few things:
> 
>   * Open issues to be still fixed (or not)
>   * Validate version of package exports
>   * Validate package import versions (most importantly
>       version ranges for implemented API)
> 
> Any opinions on how to proceed ? Do we split responsibility for checks
> and/or release cutting ?
> 
> I will pursue the Apache Felix related releases in the Apache Felix
> projects.
> 
> Thanks and Regards
> Felix
> 
> [1] https://cwiki.apache.org/SLING/towards-sling-6.html