--
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
Hi,
Hopefully, we can make a decision on this.-:)
2010/3/4 Delos dait...@gmail.com
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
Delos, +1 for your proposal.
-Jack
On Fri, Mar 5, 2010 at 4:30 PM, Delos dait...@gmail.com wrote:
Hi,
Hopefully, we can make a decision on this.-:)
2010/3/4 Delos dait...@gmail.com
Thanks for your comments! Seems no objection for more frequent releases
till now, but there still some
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/DISCUSSION-Release-GEP-more-frequently
+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
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
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
2010/3/3 Kevan Miller kevan.mil...@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
-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
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 overstaffed..
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
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
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
together
13 matches
Mail list logo
