You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@adobe.com> on 2012/11/01 09:10:08 UTC

Re: [DS] How about an SCR 1.6.2 release ?

Hi

Am 31.10.2012 um 21:31 schrieb David Jencks:

> DS 1.2:  AFAIK we've completely implemented the DS 1.2 spec.

Excellent.

>  I don't really understand the location binding and targeted PID bits.

It comes from the Configuration Admin spec and must be replicate in SCR since we basically act like a Configuration Admin service (the configuration provisioning part) towards the components.

I think we can live without this for the 1.6.2 relase.

> 
> Java 5: I'm certainly happy with not temporarily removing the java 5-isms, but I could still do it if anyone else asks.   I havent' done any basic housekeeping like removing the pre-java-5 concurrency compatibility code.  I have no strong feeling about releasing with or without this stuff.

Ok, lets release with this cruft in and cleanup after the release.

I just started a thread on the users list asking for opinions regarding our itended use to just use Java 5 features and API going forward.

Regards
Felix

> 
> thanks!
> david jencks
> 
> On Oct 31, 2012, at 12:32 PM, Felix Meschberger wrote:
> 
>> Hi
>> 
>> Am 31.10.2012 um 19:54 schrieb David Jencks:
>> 
>>> I updated the changelog from the svn log.... hopefully I didn't miss anything.
>> 
>> Just updated the changelog from the JIRA release notes.
>> 
>> Another question crossing my mind: Since the current state passes the most recent CT and checking the changes section in the 4.3 compendium spec I would assume this version also implements Version 1.2 of the DS spec. Correct ?
>> 
>> The only thing not fully implemented for the most recent specs is support for the most recent Configuration Admin features like relaxed location binding and targetted PIDs. I can live with that.
>> 
>> Regards
>> Felix
>> 
>>> 
>>> waiting for advice on the other two questions....
>>> 
>>> thanks
>>> david jencks
>>> 
>>> On Oct 31, 2012, at 8:44 AM, David Jencks wrote:
>>> 
>>>> At the moment the code uses some java 5.  How important is it that this release not require java 5?  It would not be very difficult to remove the java 5-isms and put them back after the release.
>>>> 
>>>> I've been marking defects as applying to and fixed in scr-1.8.0.  I guess we should go back and change them to 1.6.2?
>>>> 
>>>> I have not been maintaining the changelog.... that will be a bit of work.
>>>> 
>>>> If I don't discover any giant problems before we get the above done I'm fine with a release.
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>> On Oct 31, 2012, at 3:05 AM, Felix Meschberger wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I see the current trunk build passes our own as well as the OSGi CT tests and there are no open issues marked with 1.6.2.
>>>>> 
>>>>> Shall I go ahead and cut a release ?
>>>>> 
>>>>> This would IMHO also enable David to continue his refactorings.
>>>>> 
>>>>> Regards
>>>>> Felix
>>>> 
>>> 
>> 
> 


Re: [DS] How about an SCR 1.6.2 release ?

Posted by Felix Meschberger <fm...@adobe.com>.
Hi David,

Am 07.11.2012 um 06:26 schrieb David Jencks:

> Since I haven't seen any requests for pre-java-5 support  I may spend a couple minutes tomorrow cleaning up the pom and possibly removing the dependency on backport-util-concurrent.

Ok, I did it (FELIX-3747) and created a follow-up issue (FELIX-3748) should we ever want to create a pre-Java 5 build/release.

Backport Util is removed from embeddings and dependency, build is now purely Java 5 (incl. API checks) and the lock and reference wrappers are removed.

I moved FELIX-3745 (reference target property as part of service properties) to scr-1.8 and so we don't have any open issues for 1.6.2. All our integration tests and the OSGi CT tests pass.

So I am going to just cut the release.

Regards
Felix

> 
> thanks
> david jencks
> 
> On Nov 1, 2012, at 1:10 AM, Felix Meschberger wrote:
> 
>> Hi
>> 
>> Am 31.10.2012 um 21:31 schrieb David Jencks:
>> 
>>> DS 1.2:  AFAIK we've completely implemented the DS 1.2 spec.
>> 
>> Excellent.
>> 
>>> I don't really understand the location binding and targeted PID bits.
>> 
>> It comes from the Configuration Admin spec and must be replicate in SCR since we basically act like a Configuration Admin service (the configuration provisioning part) towards the components.
>> 
>> I think we can live without this for the 1.6.2 relase.
>> 
>>> 
>>> Java 5: I'm certainly happy with not temporarily removing the java 5-isms, but I could still do it if anyone else asks.   I havent' done any basic housekeeping like removing the pre-java-5 concurrency compatibility code.  I have no strong feeling about releasing with or without this stuff.
>> 
>> Ok, lets release with this cruft in and cleanup after the release.
>> 
>> I just started a thread on the users list asking for opinions regarding our itended use to just use Java 5 features and API going forward.
>> 
>> Regards
>> Felix
>> 
>>> 
>>> thanks!
>>> david jencks
>>> 
>>> On Oct 31, 2012, at 12:32 PM, Felix Meschberger wrote:
>>> 
>>>> Hi
>>>> 
>>>> Am 31.10.2012 um 19:54 schrieb David Jencks:
>>>> 
>>>>> I updated the changelog from the svn log.... hopefully I didn't miss anything.
>>>> 
>>>> Just updated the changelog from the JIRA release notes.
>>>> 
>>>> Another question crossing my mind: Since the current state passes the most recent CT and checking the changes section in the 4.3 compendium spec I would assume this version also implements Version 1.2 of the DS spec. Correct ?
>>>> 
>>>> The only thing not fully implemented for the most recent specs is support for the most recent Configuration Admin features like relaxed location binding and targetted PIDs. I can live with that.
>>>> 
>>>> Regards
>>>> Felix
>>>> 
>>>>> 
>>>>> waiting for advice on the other two questions....
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>> On Oct 31, 2012, at 8:44 AM, David Jencks wrote:
>>>>> 
>>>>>> At the moment the code uses some java 5.  How important is it that this release not require java 5?  It would not be very difficult to remove the java 5-isms and put them back after the release.
>>>>>> 
>>>>>> I've been marking defects as applying to and fixed in scr-1.8.0.  I guess we should go back and change them to 1.6.2?
>>>>>> 
>>>>>> I have not been maintaining the changelog.... that will be a bit of work.
>>>>>> 
>>>>>> If I don't discover any giant problems before we get the above done I'm fine with a release.
>>>>>> 
>>>>>> thanks
>>>>>> david jencks
>>>>>> 
>>>>>> On Oct 31, 2012, at 3:05 AM, Felix Meschberger wrote:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I see the current trunk build passes our own as well as the OSGi CT tests and there are no open issues marked with 1.6.2.
>>>>>>> 
>>>>>>> Shall I go ahead and cut a release ?
>>>>>>> 
>>>>>>> This would IMHO also enable David to continue his refactorings.
>>>>>>> 
>>>>>>> Regards
>>>>>>> Felix
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: [DS] How about an SCR 1.6.2 release ?

Posted by David Jencks <da...@yahoo.com>.
Since I haven't seen any requests for pre-java-5 support  I may spend a couple minutes tomorrow cleaning up the pom and possibly removing the dependency on backport-util-concurrent.

thanks
david jencks

On Nov 1, 2012, at 1:10 AM, Felix Meschberger wrote:

> Hi
> 
> Am 31.10.2012 um 21:31 schrieb David Jencks:
> 
>> DS 1.2:  AFAIK we've completely implemented the DS 1.2 spec.
> 
> Excellent.
> 
>> I don't really understand the location binding and targeted PID bits.
> 
> It comes from the Configuration Admin spec and must be replicate in SCR since we basically act like a Configuration Admin service (the configuration provisioning part) towards the components.
> 
> I think we can live without this for the 1.6.2 relase.
> 
>> 
>> Java 5: I'm certainly happy with not temporarily removing the java 5-isms, but I could still do it if anyone else asks.   I havent' done any basic housekeeping like removing the pre-java-5 concurrency compatibility code.  I have no strong feeling about releasing with or without this stuff.
> 
> Ok, lets release with this cruft in and cleanup after the release.
> 
> I just started a thread on the users list asking for opinions regarding our itended use to just use Java 5 features and API going forward.
> 
> Regards
> Felix
> 
>> 
>> thanks!
>> david jencks
>> 
>> On Oct 31, 2012, at 12:32 PM, Felix Meschberger wrote:
>> 
>>> Hi
>>> 
>>> Am 31.10.2012 um 19:54 schrieb David Jencks:
>>> 
>>>> I updated the changelog from the svn log.... hopefully I didn't miss anything.
>>> 
>>> Just updated the changelog from the JIRA release notes.
>>> 
>>> Another question crossing my mind: Since the current state passes the most recent CT and checking the changes section in the 4.3 compendium spec I would assume this version also implements Version 1.2 of the DS spec. Correct ?
>>> 
>>> The only thing not fully implemented for the most recent specs is support for the most recent Configuration Admin features like relaxed location binding and targetted PIDs. I can live with that.
>>> 
>>> Regards
>>> Felix
>>> 
>>>> 
>>>> waiting for advice on the other two questions....
>>>> 
>>>> thanks
>>>> david jencks
>>>> 
>>>> On Oct 31, 2012, at 8:44 AM, David Jencks wrote:
>>>> 
>>>>> At the moment the code uses some java 5.  How important is it that this release not require java 5?  It would not be very difficult to remove the java 5-isms and put them back after the release.
>>>>> 
>>>>> I've been marking defects as applying to and fixed in scr-1.8.0.  I guess we should go back and change them to 1.6.2?
>>>>> 
>>>>> I have not been maintaining the changelog.... that will be a bit of work.
>>>>> 
>>>>> If I don't discover any giant problems before we get the above done I'm fine with a release.
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>> On Oct 31, 2012, at 3:05 AM, Felix Meschberger wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I see the current trunk build passes our own as well as the OSGi CT tests and there are no open issues marked with 1.6.2.
>>>>>> 
>>>>>> Shall I go ahead and cut a release ?
>>>>>> 
>>>>>> This would IMHO also enable David to continue his refactorings.
>>>>>> 
>>>>>> Regards
>>>>>> Felix
>>>>> 
>>>> 
>>> 
>> 
>