I too wouldn't mind the ratio of time spent on bug fixes to time spent on
features, going up. I have pretty much followed the development
releases, which have seen many cool new features added, but there is still
a buglet here or there that sometimes is irksome (which are probably
already known so I won't mention them). I use jEdit primarily for Java
coding, and opening miscellaneous files (HTML, XML, etc.). I use the VFS
Browser, JBrowse, LineGuides, TextTools, and HTML plugins. So
personally, I'd of course like all these components debugged and as
stable as possible. On the other side of the coin, any concerted effort
to slim down is always great to justify jEdit as my primary editor ;)
Thanks for the great work,
> Date: Sat, 21 Oct 2000 14:03:05 +1100
> From: Slava Pestov <sp@...>
> Subject: [ jEdit-users ] PROPOSAL: quicker 2.7 release cycle?
> Hello everybody,
> Recent jEdit releases -- 2.6, 2.5 -- had rather long development cycles.
> This has several disadvantages:
> - I am the sort of person who would rather add features than fix bugs or
> update docs. So what happends is that the first few pre-releases are
> always very buggy, and the fixing takes a long time because I find it
> boring, and I am always tempted to slip in one more feature instead of
> fixing some showstopper.
> - Bug fixes in the development series take a long time to 'filter down'
> to users who would much rather use the stable version. Because I am lazy,
> I almost never 'backport' the bug fixes to the stable release (and in
> some cases, due to major changes between releases, this is impossible)
> - jEdit stable version releases are often apocalyptic, all-plugin-breaking
> With more frequent stable releases (say, every 4-6 weeks, with 1 or 2
> pre-releases per stable release), there will be less for me to debug and
> document with each release, and more time to test everything.
> Any thoughts?