geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: [DISCUSSION] Release GEP more frequently
Date Wed, 03 Mar 2010 15:46:08 GMT
2010/3/3 Kevan Miller <kevan.miller@gmail.com>

>
> On Mar 3, 2010, at 12:58 AM, Delos wrote:
>
> > Hi all,
> >
> > Johannes suggested that GEP make release more frequently. The reason is
> user may get new fixes earlier, instead of waiting for next release together
> with Geronimo server. In this way, it will be more convenient for GEP to
> provide new improvement, such as support for eclipse of latest version. To
> support it, the version number of GEP has to be redesigned.
> >
> > We need to add qualifier segment to the version number, such as 2.2.0.0,
> 2.2.0.1 and 2.2.0.2. Then, for each release of Geronimo server, GEP version
> will contains server version number as prefix and qualifier segment as 0.
> For GEP release in future, the qualifier of its version number will increase
> by 1 until server announce a new release. For example, for Geronimo server
> 2.2.0, GEP version will be 2.2.0.0; if GEP has to announce a new release
> after that,  its version will be 2.2.0.1.
> >
> > In general, GEP version will evolve as below
> > 1) Version number of GEP will contain four digitals
> > 2) If there is a G server release, GEP will announce a new release for
> it. GEP version number is three digitals of server version number suffixed
> with .0
> > 3) GEP may have several maintenance releases. Only last digital increase
> by 1 for maintenance releases version number.
> >
> > Johannes, please correct me, if there is any mistake in my description.
> >
> > Could you express your attitude toward Johannes' suggestion?
>
> Hi Delos,
> More frequent releases would certainly be a good thing. I don't see how
> anybody would object to that.
>
> Maybe I don't understand the issue (e.g. interdependencies between GEP and
> G). However, to my knowledge, there's nothing that requires GEP version
> numbers to stay exactly in sync with Geronimo server releases. So, I'm not
> sure why 4 version numbers are a *hard* requirement. So, GEP 2.2.x would
> indicate that it was built for a G 2.2.y server. You just wouldn't know how
> 'x' compares to 'y'. But a simple practice would be to get the latest GEP
> 2.2.x release.
>
> I will note that this proposal doesn't work too well for users of previous
> versions of the Geronimo server. What versions of G 2.1.x would a GEP
> 2.2.y.z correspond to? Or are you suggesting that G 2.1 users should use a
> GEP 2.1.x adapter?
>

IIRC, current approach is any GEP 2.2.* has the ability to support server
2.1.*,  2.0.*, even 1.1.*
However, I do not think it is a best practice, because as the increase of
server's version number, GEP might become more and more overstaffed.. and it
is hard to tell at which time point the lower version server is out of
service in the latest GEP. Also, for instance, if there is a new G 2.1.x
release, which version of GEP shall we update to support it, the GEP2.2.y or
GEP2.1.z or Both ?

I think the main advantage of staying the version numbers in sync with
server is that it makes user very clear to know which GEP can work with a
certain server. However, if we adopt this and make release more frequently,
we should maintenance GEP in different branch. That is, GEP
2.2.x.201012345678 only support all the 2.2.y server(where y<=x), and not
support 2.1.*, 1.1,*, so that if you try add a new server runtime in
eclipse, you won't see a pretty long list that contains all Geronimo server
versions..

-Rex


> That said, if you, other GEP devs, and especially GEP users would find this
> version scheme useful, then it sounds good to me.
>
> --kevan




-- 
Lei Wang (Rex)
rwonly AT apache.org

Mime
View raw message