The main reason why I added the 0.4-tag was to minimize te pain of writing the change log: We can filter the bugs/features according to 0.4, copy the html via view page source and transform it to the change log :-)
To the 0.4-roadmap: Normally, we hace each 1/2 year a new release. I think a good release time would be next eastern...... What can we do in this time:
- Clean up the code in someplaces. One of the most important places seem to be the code completion. One other is to finish the things we have started this release: Find references, use the framework definitions to run emonicinfirmator and scan the code, ...
- Handle better references: Add and remove them via a wizard, .....
- If we have the resources, do more quick fixes (at the moment we have only one) and programm some refactorings
- If we have the resources we should create a package explorer like java has: We can move there for example source files and correct the build file by the way.
I think, every one of us does normaly what he thinks is most important to do - and that is for me the right way to build emonic. So, the points above are rough only ideas, if You have better one, feel free to implement them :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My next step is ode completion as it is tracked in the bug/feature groups. I kindly ask to not change the following files within the next few days/ weeks:
- CSharpCompletionProcessor
- CodeInformator
- Dllinfo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's almost been three months since we had this discussion, what is everyone planning to complete/work on for 0.4? We should also decide on a date to put in a feature freeze and focus solely on bug fixes and the likes. Maybe put in a feature freeze, then bug fix for two weeks, release an RC, bug fix for two more weeks, and then 0.4?
My plans are as follows...
Will try to implement:
-improved documentation parsing providing more information
-implement an IDocumentationParser for regular xml documentation files like those provided by Microsoft's .NET SDK
-polish the NUnit support so that it is usable
-contribute more quick fixes
>I forgot to say, are we still planning to stick with Eclipse 3.2.x for our 0.4 release?
>I believe 3.3.2 will be released some time in February.
Certainly. Is there a single feature in eclipse 3.3 that is so important to drop the support for all the people using emonic under 3.2? Can't see one....
Naturally, emonic _has_ to run under eclipse 3.3, too.....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Emonic _does_ run under Eclipse 3.3, I'm using it currently.
Note that the org.emonic.debug.remote plug-in needs Eclipse 3.3. since the Target Management Plug-in needs it. Of course, nobody is forced to install this plug-in, in which case Eclipse 3.2 may still be used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Certainly. Is there a single feature in eclipse 3.3 that is so important to drop the support for all the people using emonic under 3.2? Can't see one....
> Naturally, emonic _has_ to run under eclipse 3.3, too.....
Well, menus and commands are easier to do now and doesn't seem to require as much boilerplate code. If there are other things I'll bring it up.
The fact that you bring up that Emonic has to run under Eclipse 3.3 is an important one. The fact of the matter is that we currently have to make sure Emonic runs on three different platforms, on 3.2.2, the 3.3.x maintenance builds and the 3.4 integration builds towards 3.4 in late June. Switching the 'Target Platform' all the time isn't exactly very fun and it's certainly something I don't do as often as I should (because if I did, I would've uncovered bug 1871986 a long time ago). I keep it set to 3.2.2 because I do not want to use APIs from 3.3 or 3.4 by mistake. But now when I want to test on those targets I need to switch it, and then after I'm done debugging I need to switch it back. I would also imagine that more bugs like bug 1871986 will be uncovered as the development of Emonic moves forward.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Well, menus and commands are easier to do now and doesn't seem to require as much boilerplate code.
> If there are other things I'll bring it up.
I think, this is not the point. If it is to write a view lines of code less against dropping one platform: The support of the platform wins - sorry.
The more important fact is:
How many bugs - and how serious one - do we have if we develop on 3.2 and run it on 3.3 and 3.4. My personal answer to it was until now: Not very much - eclipse is highly robust in running older plugins at newer eclipse release. Bug 1871986 seems to show that there are in fact possible problems in running this plugin on newer platforms. So, the question is: Is bug 1871986 the big exception and eclipse is so robust to plugins programmed under older frameworks that everything else runs normal (tested or not) or do we have a great number of bugs by programming under 3.2.
If bug 1871986 is the only bug caused by this programming model - sorry, then it is not worth to drop 3.2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So are we going to just keep supporting 3.2 until we find N number of bugs that are causing compatibility issues between 3.2 and up and we decide that we don't want to do this anymore?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that's my opinnion - with a N in the size about 4-6/Year.
Or when we recognize that a higher eclipse version provides a realy, realy important feature we want to support and we can do this only by dropping 3.2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What did we gain from dropping 3.1 support? One thing I can think of was CNF support, but I only added that in October after you told me the plug-in was moving away from 3.1 to 3.2 in July. So that was probably not a deciding factor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, You are right. It was probably a mistake to support 3.1 no more. But at the time I realized it the plugin used the OSGI-pligin-mechanism so it was a too great effort to move it back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My plan is the re-write of the code completion as it is written in the requirements document. I aim at the end of February 2007. Then we have 2-3 weeks for testing until the release date (remember: Easter is on March, 22nd this year...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I rearly want a new release in spring. I think, it has to be a so smooth release that at least the code searching/completion should look usefull and good. After that -> new release.....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think, I will mainly implement the features/bugs assigned now to me (and not much more). If there is still time, I will add some quick-fixes.
The main work for me will be to restructure code for searching like described in 1867930 and restructure-search.pdf, Feature 1755290, Bugs 1816780 and 1816778.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I noticed we now have a 0.4 version in the tracker. What are our target dates and plans for this next release?
The main reason why I added the 0.4-tag was to minimize te pain of writing the change log: We can filter the bugs/features according to 0.4, copy the html via view page source and transform it to the change log :-)
To the 0.4-roadmap: Normally, we hace each 1/2 year a new release. I think a good release time would be next eastern...... What can we do in this time:
- Clean up the code in someplaces. One of the most important places seem to be the code completion. One other is to finish the things we have started this release: Find references, use the framework definitions to run emonicinfirmator and scan the code, ...
- Handle better references: Add and remove them via a wizard, .....
- If we have the resources, do more quick fixes (at the moment we have only one) and programm some refactorings
- If we have the resources we should create a package explorer like java has: We can move there for example source files and correct the build file by the way.
I think, every one of us does normaly what he thinks is most important to do - and that is for me the right way to build emonic. So, the points above are rough only ideas, if You have better one, feel free to implement them :-)
My next step is ode completion as it is tracked in the bug/feature groups. I kindly ask to not change the following files within the next few days/ weeks:
- CSharpCompletionProcessor
- CodeInformator
- Dllinfo
It's almost been three months since we had this discussion, what is everyone planning to complete/work on for 0.4? We should also decide on a date to put in a feature freeze and focus solely on bug fixes and the likes. Maybe put in a feature freeze, then bug fix for two weeks, release an RC, bug fix for two more weeks, and then 0.4?
My plans are as follows...
Will try to implement:
-improved documentation parsing providing more information
-implement an IDocumentationParser for regular xml documentation files like those provided by Microsoft's .NET SDK
-polish the NUnit support so that it is usable
-contribute more quick fixes
Nice-to-have if I have time:
-add MSBuild support
-create an extension point for contributing build mechanisms (per what we discussed in Dominik and Harald's PDF file)
-let users generate documentation, see http://sourceforge.net/tracker/index.php?func=detail&aid=1775096&group_id=158390&atid=807644
Of course, if one of you wants to work on any of the above, please let me know. :)
I forgot to say, are we still planning to stick with Eclipse 3.2.x for our 0.4 release? I believe 3.3.2 will be released some time in February.
>I forgot to say, are we still planning to stick with Eclipse 3.2.x for our 0.4 release?
>I believe 3.3.2 will be released some time in February.
Certainly. Is there a single feature in eclipse 3.3 that is so important to drop the support for all the people using emonic under 3.2? Can't see one....
Naturally, emonic _has_ to run under eclipse 3.3, too.....
Emonic _does_ run under Eclipse 3.3, I'm using it currently.
Note that the org.emonic.debug.remote plug-in needs Eclipse 3.3. since the Target Management Plug-in needs it. Of course, nobody is forced to install this plug-in, in which case Eclipse 3.2 may still be used.
> Certainly. Is there a single feature in eclipse 3.3 that is so important to drop the support for all the people using emonic under 3.2? Can't see one....
> Naturally, emonic _has_ to run under eclipse 3.3, too.....
Well, menus and commands are easier to do now and doesn't seem to require as much boilerplate code. If there are other things I'll bring it up.
The fact that you bring up that Emonic has to run under Eclipse 3.3 is an important one. The fact of the matter is that we currently have to make sure Emonic runs on three different platforms, on 3.2.2, the 3.3.x maintenance builds and the 3.4 integration builds towards 3.4 in late June. Switching the 'Target Platform' all the time isn't exactly very fun and it's certainly something I don't do as often as I should (because if I did, I would've uncovered bug 1871986 a long time ago). I keep it set to 3.2.2 because I do not want to use APIs from 3.3 or 3.4 by mistake. But now when I want to test on those targets I need to switch it, and then after I'm done debugging I need to switch it back. I would also imagine that more bugs like bug 1871986 will be uncovered as the development of Emonic moves forward.
> Well, menus and commands are easier to do now and doesn't seem to require as much boilerplate code.
> If there are other things I'll bring it up.
I think, this is not the point. If it is to write a view lines of code less against dropping one platform: The support of the platform wins - sorry.
The more important fact is:
How many bugs - and how serious one - do we have if we develop on 3.2 and run it on 3.3 and 3.4. My personal answer to it was until now: Not very much - eclipse is highly robust in running older plugins at newer eclipse release. Bug 1871986 seems to show that there are in fact possible problems in running this plugin on newer platforms. So, the question is: Is bug 1871986 the big exception and eclipse is so robust to plugins programmed under older frameworks that everything else runs normal (tested or not) or do we have a great number of bugs by programming under 3.2.
If bug 1871986 is the only bug caused by this programming model - sorry, then it is not worth to drop 3.2
So are we going to just keep supporting 3.2 until we find N number of bugs that are causing compatibility issues between 3.2 and up and we decide that we don't want to do this anymore?
Yes, that's my opinnion - with a N in the size about 4-6/Year.
Or when we recognize that a higher eclipse version provides a realy, realy important feature we want to support and we can do this only by dropping 3.2
What did we gain from dropping 3.1 support? One thing I can think of was CNF support, but I only added that in October after you told me the plug-in was moving away from 3.1 to 3.2 in July. So that was probably not a deciding factor.
Yes, You are right. It was probably a mistake to support 3.1 no more. But at the time I realized it the plugin used the OSGI-pligin-mechanism so it was a too great effort to move it back.
My plan is the re-write of the code completion as it is written in the requirements document. I aim at the end of February 2007. Then we have 2-3 weeks for testing until the release date (remember: Easter is on March, 22nd this year...)
Bernhard, so what are your thoughts on my proposed time line?
I rearly want a new release in spring. I think, it has to be a so smooth release that at least the code searching/completion should look usefull and good. After that -> new release.....
I think, I will mainly implement the features/bugs assigned now to me (and not much more). If there is still time, I will add some quick-fixes.
The main work for me will be to restructure code for searching like described in 1867930 and restructure-search.pdf, Feature 1755290, Bugs 1816780 and 1816778.