Dear John, You are correct that there is "no plan". You are wrong in implying this were a prerequisite to start a new stable series. In this project, often enough the decisions for starting new releases were driven by relatively spontaneous discussions and by what might seem minor reasons to some. I do not agree to this as a valid counter-argument to start a new release cycle.
Also, I do not agree that there are "no new features." There are, and indeed quite a few, but they are indeed minor from the point of view of the majority of the users. There are several new features around business object management (e.g. customer / vendor overview page; several new reports; invoice duplication). Those features have in common that they're completely uninteresting to the home user. However, in order to make those available to non-english speaking users, they must appear in the stable series because trunk doesn't get translated. My main reason for a new stable series is to make life easier for us, the developers. Due to the source code diverging, any non-trivial bugfixing will get increasinly difficult, similar to the large difficulties with the diverging windows builds. To me, this is enough of a benefit to justify a new 2.6 cycle, even if this time there is no "one big new feature" thing as in previous releases. By the way, the 2.4 series didn't have that much convincingly new features, did it? It had the SQL backend, but this is completely uninteresting to the majority of the users who are still using an XML file. Also, it switched the HTML engine from gtkhtml to webkit, which was a big deal for us developers, but for the users it was completely uninteresting - almost no visible change for them. I mean, there are times when we have ground-braking new features, but right now there isn't such a time. Even if we completed the gtk3 port, I wouldn't consider that a very user-visible new feature. So from the point of view of the user, it doesn't make a different whether we start 2.6.0 now (and 3.0.0 in 12 months from now), or wait another 6-12 months and start 3.0.0 directly. It will only make our life more complicated due to the more diverged branches. > If we're going to do a 2.6 release we need to set some goals for it and > Geert and I should set aside the long-term work and go for those goals. > * One of the goals can certainly be Geert's credit memos and the accompanying > backend changes, but I think we need a bit more than that. > * Another can be > making sure that the SQL backend actually saves everything as soon as an > edit is completed. I already said: There are a bunch of new features in the business area which are already completed. If it's a matter of listing all of them in order to get "enough reasons" for the 2.6.0, I can surely do so, but for me those are clearly enough new things so that we can claim to bring new features. I think it's well time for a new stable series. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
