[MonoDevelop] Planning MonoDevelop 1.0
Lluis Sanchez
lluis at ximian.com
Thu Nov 30 15:20:12 EST 2006
El dj 30 de 11 del 2006 a les 19:49 +0000, en/na Paulo Aboim Pinto va
escriure:
> Hello again
>
> I remember that would be great that we could have a Solution Folder.
>
> Solution Folder is a Virtual Folder in MD Solution Tree where we could
> put all related projects. Now we can't relate projects and using a
> Solution Folder we can do that.
How is this different from support for nested solutions (which we
already have)?
>
> I think that VS2005 has this feature but I can't be sure.
>
> Regards
> Paulo Aboim Pinto (Esqueleto)
> Odivelas - Portugal
>
>
> On Thu, 2006-11-23 at 00:28 +0100, 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. 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.
> >
> > 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):
> >
> > * MonoDevelop core: The core can be considered complete now. No
> > major new features are planned. However, we need to make an
> > audit of the API to make sure we don't have public classes or
> > methods which don't really need to be public. I'd like also to
> > find some time to reorganize a bit the extension point tree
> > (which has a mixture of SharpDevelop and MonoDevelop branches),
> > to something like what I described some months ago:
> > http://lists.ximian.com/archives/public/monodevelop-list/2006-January/003077.html
> >
> > * Debugger: I know a lot of people will ask for this, but I fear
> > the debugger won't be ready by our code freeze date. We can
> > release it later on as a separate add-in.
> >
> > * 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.
> >
> > * Text editor: There are several requests/issues to solve:
> > * Parameter completion: after typing the name of a method,
> > show a popup window with information about the
> > parameters the method takes.
> > * Remove C#-isms. The code completion engine has several
> > C#-isms in the code, which may make it difficult to
> > integrate with other languages.
> > * Configurable key bindings. That's not specific to the
> > editor, but people mostly complain about it. I'm not
> > sure we can implement this for 1.0.
> > * Refactory operations. We have and under-used refactory
> > API. It would be nice to use it to implement some basic
> > refactoring operations.
> >
> > * 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).
> >
> > * ASP.NET support: I don't know if this add-in can be mature
> > enough for the 1.0 release. I'll need input on that (which
> > features could we release? would the add-in be really useful for
> > real world web projects?).
> >
> > * GTK# designer: There are several features to be implemented in
> > the designer before the release:
> > * Support partial classes when generating code.
> > * Support for Undo/Redo.
> > * Reuse the toolbox implemented for the ASP.NET add-in.
> > * Support for some missing controls, such as Gtk.Fixed and
> > context menus. It would be nice to have a TreeView
> > designer, but it may be too much work for 1.0.
> >
> > * 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?
> >
> > * NUnit: It can be considered feature complete for 1.0. The only
> > missing issue to resolve is what to do with the NUnit
> > dependency. Right now the add-in can't be built with recent
> > NUnit versions since they have breaking changes. I talked about
> > this with Charlie Poole in the Mono summit and he suggested to
> > embed the most recent NUnit dlls into the add-in, since even if
> > the API has some breaking changes, new NUnit versions can still
> > run tests written for all the previous versions.
> >
> > * 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.
> >
> > * Welcome page: It looks ok to me.
> >
> > * Web references: I'd like to integrate the web references add-in
> > implemented by Gideon de Swardt. The only problem I see is that
> > it only supports .NET 2.0 projects. It would be nice to make it
> > work for 1.1 as well.
> >
> > * Xml editor: It's being maintained outside of MD, so nothing to
> > add. Just to make sure it works when we release 1.0.
> >
> > * Boo: I think this add-in is complete, but I'd also like to know
> > the opinion of Peter about this. In any case, there is one issue
> > that should be fixed: right now the Boo add-in always starts an
> > external process which runs the backend for the Boo shell. This
> > process should only be started if the user opens the shell,
> > since it's a waste of memory otherwise.
> >
> > * CSharp: It is mostly complete. We may need to add support for
> > partial classes. I'm not sure they are correctly handled by the
> > parser right now.
> >
> > * ILAsm: I haven't used it for a long time. I guess it works.
> >
> > * Java: It's mostly complete, although there are some IKVM
> > configuration issues that need to be fixed.
> >
> > * VB.NET: I don't think there is support for generics. We may want
> > to migrate to the new VB compiler.
> >
> > * Nemerle: Don't know much about the status. Any input? 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.
> >
> > * ChangeLog add-in: It's now integrated with the version control
> > add-in. There are ideas for improving it.
> >
> > * Autotools: There are several features I'd like to support for MD
> > 1.0:
> > * Support integration with existing Makefiles. That is, if
> > somebody has a project with complex build rules which
> > can't be emulated by MD, just make it possible to
> > delegate the entire build process to Make, and still be
> > able to launch the build from inside MD. About modifying
> > the Makefile in MD, I think supporting adding/removing
> > files would be enough for now.
> > * We need to find a solution for file templates (.in
> > files). MD uses some of them. We need to support them in
> > the MD build model if we want to be able to completely
> > build MD using MD.
> > * There may be other missing features needed for
> > self-hosting MD.
> > * It would be nice to support generating a tarball without
> > having to pollute the project directory with autotools
> > files.
> >
> > * IDE extensions for Mono: Nothing much to do. Just make sure it
> > works with the most recent Mono makefiles.
> >
> > As you can see that's a lot of work. I think we should prioritize
> > working on features related with development GNOME desktop applications
> > (which has been the main goal of MD anyway).
> >
> > I'd like to get feedback about this plan. I may not have a complete view
> > of every add-in, and I'm sure I'm missing things.
> >
> > Thanks!
> > Lluis.
> >
> >
> >
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
More information about the Monodevelop-list
mailing list