[MonoDevelop] Planning MonoDevelop 1.0
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!
> 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
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
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
> * 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
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
ALT Linux Sisyphus
More information about the Monodevelop-list