We would like to have one month beta, and one month release candidate. so beta first of February, release candidate first of March. We would open 1.5alpha either in rc or at the end of March. Stef On Jan 13, 2012, at 7:37 AM, Luc Fabresse wrote:

2012/1/12 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi

since we will not have OPAL as preview in 1.4 and we do not need to change the refactoring engine code, we will unload AST and RBEngine package from the system and start to pass in 1.4 beta probably at the end of the month. One idea was that we could have decent tools to work on the core but this is not the case.

We will encourage people to try their packages to 1.4 beta and rc so that we can produce 1.4.

It is excellent that 1.4 is planned for soon. Do you have dates/planning in mind?

Luc

Stef

thanks. May be I will add SystemAnnouncement and RPackage since this is stable. We will check if we can push or not in 1.4 the clean of the eventBuff. Stef

Very good idea to release what we have and continue with open stuff in 1.5. Feels just right!

Norbert

Am 12.01.2012 um 21:54 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

Hi

since we will not have OPAL as preview in 1.4 and we do not need to change the refactoring engine code, we will unload AST and RBEngine package from the system and start to pass in 1.4 beta probably at the end of the month. One idea was that we could have decent tools to work on the core but this is not the case.

We will encourage people to try their packages to 1.4 beta and rc so that we can produce 1.4.

Stef

On Jan 13, 2012, at 4:09 PM, Henrik Johansen wrote:

On Jan 13, 2012, at 1:18 44PM, Stéphane Ducasse wrote:

...

thanks. May be I will add SystemAnnouncement and RPackage since this is stable. We will check if we can push or not in 1.4 the clean of the eventBuff.

Stef

See issue 5172 - 5174 for my comments.

TLDR; I don't think it's a good idea to include in Core for 1.4, a more pervasive integration with the base system would be desirable, so one could remove the old event-based system at the same time.

Up until here I agree.

(but have a backwards-compatible external package)

I think that it will be difficult enough to swap the two events notification systems and that we will not make a backward compatible package. I think that for migrating the few users will just have to register to the new one. Now give me 10 full time engineers and we do it. At the end of the day, we should do some reality checks and put resources on the right items. Stef

Cheers, Henry

On Jan 13, 2012, at 11:14 PM, Henrik Johansen wrote:

On Jan 13, 2012, at 9:44 30PM, Stéphane Ducasse wrote:

...

...

(but have a backwards-compatible external package)

I think that it will be difficult enough to swap the two events notification systems and that we will not make a backward compatible package. I think that for migrating the few users will just have to register to the new one. Now give me 10 full time engineers and we do it. At the end of the day, we should do some reality checks and put resources on the right items.

Stef

I'm talking of existing external users of the SystemChangeNotifier, like (assumption on my part) OCompletion, OB, Coral and others. Implementing a backwards-compatible protocol as one of the steps shouldn't be too hard, is probably needed to keep the system running while swapping out the existing one anyways, and will ease migration of the external packages by keeping them loadable with the backwards-compat package in in image.

To avoid another rant of getting legs kicked out from under one as part of an upgrade, and provide a generally pleasant upgrade experience for everyone, I think it is crucial.

I know now this is a question of energy/time.

If I can make it in May, I'll work on it.

Thanks

Cheers, Henry