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".
* 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
