Re: [VOTE] Release Felix Http Service version 2.0.0
On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.orgwrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Best Regards, Sten Roger Sandvik
Re: [VOTE] Release Felix Http Service version 2.0.0
what version of maven did you use? regards, Karl On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hall he...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.orgwrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Best Regards, Sten Roger Sandvik -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Felix Http Service version 2.0.0
I noticed that I was not running the absolute last version. Will upgrade to 2.2.1... On Thu, Oct 1, 2009 at 11:32 AM, Richard S. Hall he...@ungoverned.orgwrote: On 10/1/09 11:16, Sten Roger Sandvik wrote: Used version 2.2.0 on Mac (OSX 10.6). Well, you can always try to update to 2.2.1... On Thu, Oct 1, 2009 at 11:12 AM, Karl Paulskarlpa...@gmail.com wrote: what version of maven did you use? regards, Karl On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.orgwrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific
Re: [VOTE] Release Felix Http Service version 2.0.0
Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hall he...@ungoverned.orgwrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to
Re: [VOTE] Release Felix Http Service version 2.0.0
On 10/1/09 16:36, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] While this is true, it really depends when it comes to micro releases. For the framework we are typically working toward the next minor release, e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it is only a maintenance release, then we release it as 2.0.1 and there never was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words, our trunk is never a micro release, it is always a minor (or major) release. On the other hand, if a subproject operates as a micro release in trunk, then yes they should likely follow the even/odd numbering strategy to avoid version number inversion like you suggest. - richard Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.orgwrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since
Re: [VOTE] Release Felix Http Service version 2.0.0
So, what you guys are saying is... * Keep trunk as a major release, ex 2.1.0-SNAPSHOT. * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT. * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. Right? /srs On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hall he...@ungoverned.orgwrote: On 10/1/09 16:36, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] While this is true, it really depends when it comes to micro releases. For the framework we are typically working toward the next minor release, e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it is only a maintenance release, then we release it as 2.0.1 and there never was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words, our trunk is never a micro release, it is always a minor (or major) release. On the other hand, if a subproject operates as a micro release in trunk, then yes they should likely follow the even/odd numbering strategy to avoid version number inversion like you suggest. - richard Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue
Re: [VOTE] Release Felix Http Service version 2.0.0
Hi, Sten Roger Sandvik schrieb: So, what you guys are saying is... * Keep trunk as a major release, ex 2.1.0-SNAPSHOT. * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT. * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. Right? I personally, and my framework, find this confusing. Consider this: * my app is running 2.0.2 * testing some stuff in 2.1.0-SNAPSHOT * now 2.0.4 is released (including the tested stuff) * so now I have to downgrade to 2.0.4 This works by manually downgrading. Using OBR such a downgrade is not easily possible. For this reason, I more like this: * work on 2.0.1-SNAPSHOT (trunk) * release micro release 2.0.2 * continue with 2.0.3-SNAPSHOT in trunk * decide to do a minor release 2.2.0 * continue with 2.2.1-SNAPSHOT in trunk This way we have a strictly increasing version numbering and only upon release we decide what kind of release we do and have not interruption or downgrade Recent examples of me having done this is Web Console, which I release to 2.0.0 after working at 1.2.11-SNAPSHOT in trunk or Configuration Admin, which was released 2.0.0 after working at 1.0.11-SNAPSHOT in trunk. Finally, I plan on release the SCR bundle at 1.2.0 while currently I have it a 1.0.9-SNAPSHOT until ready for release. Just my €.02 Regards Felix /srs On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hall he...@ungoverned.orgwrote: On 10/1/09 16:36, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] While this is true, it really depends when it comes to micro releases. For the framework we are typically working toward the next minor release, e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it is only a maintenance release, then we release it as 2.0.1 and there never was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words, our trunk is never a micro release, it is always a minor (or major) release. On the other hand, if a subproject operates as a micro release in trunk, then yes they should likely follow the even/odd numbering strategy to avoid version number inversion like you suggest. - richard Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under
Re: [VOTE] Release Felix Http Service version 2.0.0
Oh. Right. Now I see. You and Felix has actually the same method, except one uses minor odd/even strategy vs major odd/even strategy? On Thu, Oct 1, 2009 at 5:15 PM, Richard S. Hall he...@ungoverned.orgwrote: On 10/1/09 17:01, Sten Roger Sandvik wrote: So, what you guys are saying is... * Keep trunk as a major release, ex 2.1.0-SNAPSHOT. * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT. Yes, this part would be ok, but... * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. No, in this case there will never be a 2.1.0 release, since 2.1.0-SNAPSHOT would be greater. Here, you'd follow the odd/even strategy, so 2.1.0-SNAPSHOT would be the development version and when you cut a release for 2.1.0-SNAPSHOT, it would be released as 2.2.0 and the trunk would become 2.3.0-SNAPSHOT. Make sense? - richard Right? /srs On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hallhe...@ungoverned.org wrote: On 10/1/09 16:36, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] While this is true, it really depends when it comes to micro releases. For the framework we are typically working toward the next minor release, e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it is only a maintenance release, then we release it as 2.0.1 and there never was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words, our trunk is never a micro release, it is always a minor (or major) release. On the other hand, if a subproject operates as a micro release in trunk, then yes they should likely follow the even/odd numbering strategy to avoid version number inversion like you suggest. - richard Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall he...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should
Re: [VOTE] Release Felix Http Service version 2.0.0
I think this approach is fine too. However, OBR should be able to downgrade as easily as upgrade... - richard On 10/1/09 17:12, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: So, what you guys are saying is... * Keep trunk as a major release, ex 2.1.0-SNAPSHOT. * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT. * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. Right? I personally, and my framework, find this confusing. Consider this: * my app is running 2.0.2 * testing some stuff in 2.1.0-SNAPSHOT * now 2.0.4 is released (including the tested stuff) * so now I have to downgrade to 2.0.4 This works by manually downgrading. Using OBR such a downgrade is not easily possible. For this reason, I more like this: * work on 2.0.1-SNAPSHOT (trunk) * release micro release 2.0.2 * continue with 2.0.3-SNAPSHOT in trunk * decide to do a minor release 2.2.0 * continue with 2.2.1-SNAPSHOT in trunk This way we have a strictly increasing version numbering and only upon release we decide what kind of release we do and have not interruption or downgrade Recent examples of me having done this is Web Console, which I release to 2.0.0 after working at 1.2.11-SNAPSHOT in trunk or Configuration Admin, which was released 2.0.0 after working at 1.0.11-SNAPSHOT in trunk. Finally, I plan on release the SCR bundle at 1.2.0 while currently I have it a 1.0.9-SNAPSHOT until ready for release. Just my €.02 Regards Felix /srs On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hallhe...@ungoverned.orgwrote: On 10/1/09 16:36, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] While this is true, it really depends when it comes to micro releases. For the framework we are typically working toward the next minor release, e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it is only a maintenance release, then we release it as 2.0.1 and there never was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words, our trunk is never a micro release, it is always a minor (or major) release. On the other hand, if a subproject operates as a micro release in trunk, then yes they should likely follow the even/odd numbering strategy to avoid version number inversion like you suggest. - richard Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. - richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it
Re: [VOTE] Release Felix Http Service version 2.0.0
Sorry. Yes. On Thu, Oct 1, 2009 at 5:22 PM, Richard S. Hall he...@ungoverned.orgwrote: On 10/1/09 17:17, Sten Roger Sandvik wrote: Oh. Right. Now I see. You and Felix has actually the same method, except one uses minor odd/even strategy vs major odd/even strategy? Micro and minor, but yes. - richard On Thu, Oct 1, 2009 at 5:15 PM, Richard S. Hallhe...@ungoverned.org wrote: On 10/1/09 17:01, Sten Roger Sandvik wrote: So, what you guys are saying is... * Keep trunk as a major release, ex 2.1.0-SNAPSHOT. * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT. Yes, this part would be ok, but... * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT. No, in this case there will never be a 2.1.0 release, since 2.1.0-SNAPSHOT would be greater. Here, you'd follow the odd/even strategy, so 2.1.0-SNAPSHOT would be the development version and when you cut a release for 2.1.0-SNAPSHOT, it would be released as 2.2.0 and the trunk would become 2.3.0-SNAPSHOT. Make sense? - richard Right? /srs On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hallhe...@ungoverned.org wrote: On 10/1/09 16:36, Felix Meschberger wrote: Hi, Sten Roger Sandvik schrieb: You are right. We should probably skip version 2.0.0 and go ahead to do a version 2.0.1. I do not tag 2.0.0 since it's a failed release. Or brather 2.0.2 because this is bundle release. The reason has been outline before but basically it is because Maven thinks 2.0.1 is more recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more recent. For this reason we reserve odd numbers for SNAPSHOTs and even numbers for releases. [This rule only applies for bundles and not for maven bundles were we just increment as usual] While this is true, it really depends when it comes to micro releases. For the framework we are typically working toward the next minor release, e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it is only a maintenance release, then we release it as 2.0.1 and there never was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words, our trunk is never a micro release, it is always a minor (or major) release. On the other hand, if a subproject operates as a micro release in trunk, then yes they should likely follow the even/odd numbering strategy to avoid version number inversion like you suggest. - richard Regards Felix / srs On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hall he...@ungoverned.org wrote: On 9/30/09 23:31, Sten Roger Sandvik wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? For me, personally, I don't care. However, officially, the issue is since it was a failed release, we shouldn't release it all, because some people might have grabbed the last JARs and are treating them as the official release knowingly or not. So, the only way to prevent that is to not have that release version at all, which means we do 2.0.1 instead. As for why the digests failed in the first place, I don't really know. I thought Maven just did this automatically. I am a release newbie myself, so maybe someone else has some advice. -richard BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall he...@ungoverned.org wrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses.
Re: [VOTE] Release Felix Http Service version 2.0.0
Not that many votes yet :-) Do people need more time to test the release? BR, Sten Roger Sandvik On Tue, Sep 29, 2009 at 9:49 AM, Rob Walker r...@ascert.com wrote: Our release process has been delayed, so haven't had a chance to try the new Http in our environment. Happy to add my +1 though if others have and it's working well for them - R
Re: [VOTE] Release Felix Http Service version 2.0.0
Hehe. Not worried. Just... well... a little worried :-) On Wed, Sep 30, 2009 at 5:39 PM, Richard S. Hall he...@ungoverned.orgwrote: Don't worry, I am sure people are just busy...I am. The vote needs to run for a minimum of 72 hours...that is not the deadline... - richard On 9/30/09 17:16, Sten Roger Sandvik wrote: Not that many votes yet :-) Do people need more time to test the release? BR, Sten Roger Sandvik On Tue, Sep 29, 2009 at 9:49 AM, Rob Walkerr...@ascert.com wrote: Our release process has been delayed, so haven't had a chance to try the new Http in our environment. Happy to add my +1 though if others have and it's working well for them - R
Re: [VOTE] Release Felix Http Service version 2.0.0
On Wed, Sep 30, 2009 at 5:16 PM, Sten Roger Sandvik s...@x3m.com wrote: Not that many votes yet :-) Do people need more time to test the release? Hi Stan, I've done some testing already (for the httpservice especially), but as far as I'm concerned I'll need some more time to try the bridge and the whiteboard part. Hopefully next week :-) Regards, -- Filippo Diotalevi
Re: [VOTE] Release Felix Http Service version 2.0.0
-1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Best Regards, Sten Roger Sandvik
Re: [VOTE] Release Felix Http Service version 2.0.0
Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall he...@ungoverned.orgwrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Best Regards, Sten Roger Sandvik
Re: [VOTE] Release Felix Http Service version 2.0.0
Now all the issues that Richard noted is fixed. Verified it a couple of times so I think it's right this time. Only issue that remains is MD5/SHA1 missmatch. When I have figured that out I will propose a new release candidate 2.0.0. Regards, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:55 PM, Sten Roger Sandvik s...@x3m.com wrote: Hi all. Sorry about problems with the release. I have now rolled back to before the release candidate preparation. Will fix the issues raies by Richard and try again. All artifacts is not available in the staging repository anymore, but can be accessed using apache.snapshot repository. BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:31 PM, Sten Roger Sandvik s...@x3m.com wrote: Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also will fix the issues that you are listing here. Was not sure how to do the NOTICE file so it was just a copy from something else :-) Do it need to be a 2.0.1 release? Could I just rollback the release by rolling back the pom's and delete the tag? BR, Sten Roger Sandvik On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall he...@ungoverned.orgwrote: -1 There are quite a few issues, but it is really not all that bad...actually, there is only one issue that is causing me to give a -1, which is the fact that the MD5 and SHA1 digests don't appear to match for me. Not sure why that would be the case. There are also a raft of other more minor issues that would not have caused a -1 necessarily, but now we can fix those too. They are: * The dependencies on OSGi should be on the official JARs at the appropriate version level needed (i.e., lowest acceptable version). * It appears that all NOTICE use the same name (Apache Felix HTTP Service), but it should be different for each subproject module. For example, the bridge module should be Apache Felix HTTP Service Bridge. * NOTICE file for api says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for base says it includes OSGi code, but it doesn't. Should also include Apache under uses. * NOTICE file for bridge should include Apache under uses. * NOTICE file for bundle should include Apache under uses. * NOTICE file for jetty should include Apache under uses. * NOTICE file for proxy says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples bridge WAR file is not in META-INF directory, neither are LICENSE files. Should verify dependencies listed in NOTICE file. * NOTICE for samples filter says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for samples whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. * NOTICE for whiteboard says it includes OSGi, but it only uses. Also should include Apache in uses. Note that if we have dependencies on Apache software, we still list them in the uses section of the NOTICE file...this is overly cautious, but not a big deal if we already have to keep track of third-party dependencies. Doing a release is difficult, so trying it as a newbie is to be commended. :-) At this point, we will need to scrap this release and do a 2.0.1 release with fixes for all of the above. Still, the main issue was the digests. Sorry, but good work none the less. Let me know if you have any questions. - richard On 9/28/09 22:59, Sten Roger Sandvik wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Best Regards, Sten Roger Sandvik
Re: [VOTE] Release Felix Http Service version 2.0.0
Our release process has been delayed, so haven't had a chance to try the new Http in our environment. Happy to add my +1 though if others have and it's working well for them - R
[VOTE] Release Felix Http Service version 2.0.0
Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. This is my first release ever so hopefully I have done all the things right :-) We solved 7 issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224 There are 8 outstanding issues: https://issues.apache.org/jira/browse/FELIX/component/12310340 Staging repository: https://repository.apache.org/content/repositories/felix-staging-007/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 007 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Best Regards, Sten Roger Sandvik
Re: [VOTE] Release Felix Http Service version 2.0.0
On Mon, Sep 28, 2009 at 10:59 PM, Sten Roger Sandvik s...@x3m.com wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. [..] Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Sten, is it possible to have a minimal documentation for the new bundle? I'd like to give it a try with a few applications I have, but I don't really know which submodule to use... -- Filippo Diotalevi
Re: [VOTE] Release Felix Http Service version 2.0.0
Yes, will try to finish somthing very soon. But here's a brief explanation of the bundles that is important: * jetty - Ready to run bundle that starts jetty (same as the previous 1.0.1 bundle), but with filter support trough org.apache.felix.http.api.ExtHttpService. * whiteboard - Bundle that enabled whiteboard functionality for any HttpService. If it detects ExtHttpService, filters can be deployed sa well (see samples/whiteboard for a very simple example). * bridge - Used when deployed inside a web container. This bundle must be used with proxy bundle. Bridge is deployed in the OSGi engine and proxy is deployed in the web container (see samples/bridge for a simpe example on how to use). * bundle - A bundle that has jetty, bridge and whiteboard functionality into the same bundle. This is possible the only bundle you ever need to use. Can enable/disable features using some properties (org.apache.felix.http.jettyEnabled, org.apache.felix.http.whiteboardEnabled). * samples/bridge - Ilustrates how to use bridged mode (deployed inside an existing servlet contiainer). * samples/filters - This just illustrates how to use filters using ExtHttpService. * samples/whiteboard - Simple example using whiteboard bundle for registering servlets and filters. Hope this helps a little until documentaiton is in place. BR, Sten Roger Sandvik On Tue, Sep 29, 2009 at 1:12 AM, Filippo Diotalevi filippo.diotal...@gmail.com wrote: On Mon, Sep 28, 2009 at 10:59 PM, Sten Roger Sandvik s...@x3m.com wrote: Hi. I have prepared a release candidate for the improved http service that I contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major refactoring and includes much more functionality than the original http.jetty module. Docs will be available on wiki very soon. [..] Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Sten, is it possible to have a minimal documentation for the new bundle? I'd like to give it a try with a few applications I have, but I don't really know which submodule to use... -- Filippo Diotalevi
