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. Hall<he...@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".
* 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
