arguments are valid for releases of Geronimo server
> themselves, aren't they?
>
> Juergen
>
>
> --
> View this message in context:
> http://n3.nabble.com/DISCUSSION-Release-GEP-more-frequently-tp425481p430461.html
> Sent from the Development mailing list archive at Nabble.com.
>
--
Best Regards,
Delos
+1 on adding a forth digit, while maintaining existing 1.1-2.2 server
support in the same GEP 2.2.x.x build, along with some wiki updates
explaining which versions should be used for given server/Eclipse
combinations.
-Donald
On 3/5/10 3:30 AM, Delos wrote:
> Hi,
>
> Hopefully, we can make a de
ovement, such as support for eclipse of latest version. To support
> it, the version number of GEP has to be redesigned.
>
Actually, this arguments are valid for releases of Geronimo server
themselves, aren't they?
Juergen
--
View this message in context:
http://n3.nabble.com/DIS
Delos, +1 for your proposal.
-Jack
On Fri, Mar 5, 2010 at 4:30 PM, Delos wrote:
> Hi,
>
> Hopefully, we can make a decision on this.-:)
>
> 2010/3/4 Delos
>
> Thanks for your comments! Seems no objection for more frequent releases
>> till now, but there still some advices about implementation
Hi,
Hopefully, we can make a decision on this.-:)
2010/3/4 Delos
> Thanks for your comments! Seems no objection for more frequent releases
> till now, but there still some advices about implementation details.Here are
> my answers to some of your questions.
>
> *1) (Kevan) I will note that thi
Thanks for your comments! Seems no objection for more frequent releases
till now, but there still some advices about implementation details.Here are
my answers to some of your questions.
*1) (Kevan) I will note that this proposal doesn't work too well for users
of previous versions of the Geronim
On Mar 3, 2010, at 10:46 AM, Rex Wang wrote:
>
> 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 overstaff
-1 to a branch per server release (like GEP 2.1.x only works with Server
2.1.x) as this would create a maintenance nightmare, where we would now
have to fix a given bug or add a new feature (or upgrade to a newer
Eclipse level) in 4 branches (1.1, 2.0, 2.1, 2.2) instead of just one.
For 3.0, we sh
2010/3/3 Kevan Miller
>
> 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 con
Adding a forth digit is an option, but not sure if that is an Eclipse
best practice unless it as a _vDate (maybe Tim would have some
background knowledge of this, as it seems we discussed doing this
several years ago)
For OpenJPA, we had an Eclipse plugin contributed to us, which uses a
new Ma
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
> n
Hello Delos,
that's exactly what I meant. Thank you for bringing it into discussion!
Johannes
Am 03.03.2010 06:58, schrieb Delos:
> 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
> toge
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 versi
13 matches
Mail list logo
