[MonoDevelop] Planning MonoDevelop 1.0

Ildar Mulyukov ildar at users.sourceforge.net
Thu Nov 23 04:23:46 EST 2006


On 23.11.2006 05:28:39, Lluis Sanchez wrote:
> Hi all!

Hi Lluis!


>  After several years of development MonoDevelop is beginning to be   
> really  useful to develop real applications, so I think it makes  
> sense to  start planning a stable 1.0 release.

I am sorry, but my 1st thought was: isn't it too early? But after some  
time of thinking I came to the conclusion, that for THE CORE it's OK.  
But considering many of AddIns, I'd say, it's too early.

> My proposal is the following:
> * MD beta 1 release around mid January (two months from now). In      
> this release we would include most of the missing  features for       
> 1.0 (see below). We would do code freeze at    this point.
> * MD beta 2 (or RC) release around mid February. Mainly bug  fixes     
> and memory usage reduction.
> * MD 1.0 release around mid March. It will include the latest  bug     
> fixes. I also think we should work on writing documentation  for       
> this release, specially tutorials.

OK. But please, please, make frequent 0.9.* releases. This would  
attract more testers and distro maintainers like me to package  
versions. (Distro guys like VERSIONs much more then SVN snapshots)

> So, which features is MD 1.0 going to include?. I'd like to get input  
> from contributors and users about that, but I think what we should do  
> is  to finish and polish what we already have.
> 
> I went through all add-ins and I have written down some notes about
> what's missing on each of them (bugs aside):
> 
> * Documentation browser: The Monodoc integration more or less  works,  
> but there are some known crashes. However I still  believe     that  
> showing Monodoc in an external window would be more           
> practical that the current integrated view. The integrated           
> documentation tree is not really useful, we don't have search  or      
> an index integrated.

Is it possible to make an alternative: built-in or monodoc.exe from  
mono-tools (AKA monodoc GUI) ?
Reason: I know that monodoc classes are used for code completion, so  
it's a bad idea to tear off the monodoc. But having external monodoc  
GUI is quite memory-expensive. I guess, that calling monodoc.exe from  
inside the same mono VM, that MD is in, would low memory-usage figure.  
After all, you can make a switch in preferences to use  
internal/external monodoc, ha?

> * Text editor: There are several requests/issues to solve:
>    * Remove C#-isms. The code completion engine has  several          
> C#-isms in the code, which may make it difficult to                   
> integrate with other languages.

Agree, this is quite important. Mono/CLR/M$.Net is language  
independent, and this is important to keep in mind.

> * VS importer: Ankit is working on supporting VS2005 files  right      
> now. The idea is that you can open VS files directly in MD  and        
> work with those projects like if they were native projects.  It        
> will support writing changes such as adding files or  modifying        
> the project configuration. Ideally, we should do the same for          
> VS2003 (right now it only supports importing for VS2003           
> projects).

I sincerely glad for VS users.
But what is REALLY missing is the possibility to build MD projects  
without a GUI. E.g. if someone has a dedicated server for building  
projects. I know of autotools. But IMO it's too hard to match MD  
solution+projects to autotools set of files. From "matching" point of  
view, MD project is much closer to NAnt. So I think, having NAnt  
support would be much more useful and straightforward. I know of the  
try to implement NAnt support, but AFAIK there's nothing useful right  
now. Or, if there's, I would be glad to see it working with MD-1.0

> * GTK# designer: There are several features to be implemented  in      
> the designer before the release:

BTW, is Stetic used somewhere outside the MD?

> * MonoQuery database management: I have no idea of what is the status  
> of this add-in. I have never really used it. Can  somebody     give  
> input about it? Do we want to support it for 1.0?

Ok. MonoQuery brings a great idea of having access to Databases, that  
are used for application development. But for this purpose it misses  
several things.
1. It should store it's configuration data in Solution file, not in MD  
config dir. In other words, it should be per project.
2. It should make use of reflections. Requiring Sybase, IBM DB2 is  
overkill for RAD/IDE. The DB code, that uses reflection can be found in  
SqlSharpGtk project:  
http://forge.novell.com/modules/xfmod/project/?sqlsharpgtk

> * Version Control: I recently integrated some of the changes  done     
> for the Google SoC project and improved it a lot. Support for          
> SVN is mostly functional. What's missing is support for CVS.  It       
> would be nice to have for MD 1.0.

IMHO AFAIK the SCM, that's going to become a winner is GIT. Any plans?

>       * Nemerle: Don't know much about the status. Any input?

I am a nemerlite!

>         The big
>         problem I find is that it depends on a specific version of
>         Nemerle from SVN. If it can't be made to depend on a packaged
>         Nemerle version we won't be able to include it in the MD
>         release.

Well, the good news is: Nemerle project already preparing to 1.0  
release in similar way, as MD. So I expect that it will enter the  
feature freeze / ABI freeze early enough to be MD-1.0-ready. I'd like  
to listen to the guy, who made a great effort to nemerle-lang AddIn. As  
soon, as I build SVN version of MD, I'll make some bug reports.
In fact, as for MD-0.12 + Nemerle SVN is quite good and useful.

Best regards, Ildar.
-- 
Ildar  Mulyukov,  free SW designer/programmer
================================================
email: ildar at users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================


More information about the Monodevelop-list mailing list