felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sten Roger Sandvik <...@x3m.com>
Subject Re: [VOTE] Release Felix Http Service version 2.0.0
Date Thu, 01 Oct 2009 15:29:17 GMT
I actually find this clearer too. Like the odd/even micro release scheme.
Will then try to release version 2.0.2 of http service when I have fixed the
md5/sha1 issue.

On Thu, Oct 1, 2009 at 5:12 PM, Felix Meschberger <fmeschbe@gmail.com>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. Hall <heavy@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<heavy@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<
> heavy@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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message