Re: [xtext-dev] 0.7.1 and beyond

[Peter Friese <peter.friese@xxxxxxxxx>]

Hi,

just to clarify things:

Xtext 0.7.1 is a maintenance release and we do not want to push any  
new features - right?.

As an example, Michael's folding support (https://bugs.eclipse.org/bugs/show_bug.cgi?id=281429 
) will not make it into 0.7.1? How about mini-features like e.g.  
adding "format" and "toggle comments" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=281055 
 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=280200) to the  
context menu. What about the wizard enhancements that have been  
requested?

To put it more bluntly, what's the threshold? Will we only fix bugs,  
or will we add features?

I'd be fine with only fixing bugs for 0.7.1. If someone wants to work  
on new features, they can do this in their workspace and attach the  
changes as patches to the respective feature bugs (AFAIK, this is also  
the way the EMF team operates).

Opinions?

Cheers,
Peter

On 30.06.2009, at 11:27, Sven Efftinge wrote:

> Hi all,
>
> thanks again for all the work you did the last couple of months and  
> especially the days before the release.
> Now that the release is out, the plan is to
>
> *Have a 0.7.1 of Xtext, Xpand and MWE on July 17th*
> I have added 0.7.1 version tags for the various bugzilla products.
> Sebastian and I already flagged a couple of Xtext bugs with 0.7.1.
> Take these bugs as prioritized and if you want to do something for  
> your favorite project, go ahead and fix one of them. :-)
> If you're not sure about your fix, feel free to provide a patch so  
> someone else can review it before it goes into CVS.
> Of course there might come up some additional more important bugs  
> (or we may have overlooked some).
> Feel free to discuss.
>
> *Important*
> Please, if you fix a bug (or add new functionality) you always need  
> to *provide test cases*.
> It is proven and best practice to write the test which reproduces  
> the bug first and fix it afterwards.
> Also if a contribution enhances or changes documented information,  
> *update the docs*.
>
> That said, I know that there are parts which are hard to test (e.g.  
> UI code). We need to leverage Dependency Injection in order to  
> decouple
> functionality from UI, so that they can be unit tested in isolation.  
> This will also enforce a nicer architecture.
> Long running unit tests are not that helpful.
>
> *Documentation*
> There are still some things which need to be documented.
> In Xtext this is :
> - check modes
> - managing-concurrency : UI multi threading / UnitOfWork / access to  
> node model
>
> Also Christian recently filed a couple of bugzillas pointing to  
> missing pieces in the Xpand and MWE documentation.
>
> Those can be fixed at all times, of course.
>
> *Beyond 0.7.1 (i.e. 0.8.0)*
> We need to clean up our development environment. Turnarounds have  
> become very slow lately. This is due to slow CVS access and long  
> running code generation, unit tests execution. Also the setup of a  
> development environment is not as easy it should be.
> Most important: We need a build which allows for local execution and  
> which we understand.
> Dennis and Sebastian will investigate.
>
> After the 0.7.1 (Jul-17) release we will create a branch for the 0.7  
> stream and are able to change major things for the next version  
> (0.8.0).
> Knut and Michael already have submitted patches for new features,  
> which could be further worked on then.
>
> Cheers,
> Sven
>
> _______________________________________________
> xtext-dev mailing list
> xtext-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/xtext-dev