On Oct 10, 7:43 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Oct 9, 7:17 pm, Christian Boos <[EMAIL PROTECTED]> wrote: > > >> Christopher Lenz wrote: > > >>> I must say that I'd consider that kind of change/vision outside of > >>> the scope of even Trac 1.0. > > > ... > > >>> We will need to sort this out *somehow* for the future. Here's what > >>> *I* want: us to release a 1.0 version sometime in this decade, and > >>> postpone any big vision shifts until after that point. > > > ... > > >>> What I want is to fix the big problems we still have, for example > >>> I18n or documentation/help. I don't yet want to think about multi- > >>> project support, a generic resource system used throughout the code, > >>> or big changes to the plugin/component system. > > >>> There's a life after 1.0, if we even ever reach that point. > > > ... > > >> Well, multi-project support has always been a 1.0 goal, for one. > >> Improved change notification is a topic for 0.12, I think (#1890 and > >> the like). But we'll have other occasions to talk about all this... > > > what do you think about adopting a model like git development, who > > release/tag very often, say every 2 weeks or one month. see > >http://repo.or.cz/w/git.git?a=tagsfor their tag history, and here for > > their branch/merge > > history:http://repo.or.cz/git-browser/by-commit.html?r=git.git > > . > > > what version would be called 1.0 should not matter imo, we are using > > it since one year productive, stable and with great pleasure so nobody > > would complain about calling 0.10 1.0. and also after 1.0 there may be > > incompatible changes, thats life that somebody may come up with a > > better idea how to do something. > > 1.0 is a statement about API stability. At that point we need to be > really sure internals aren't going to change. Thats hard. So yes, it > matters.
sorry for distracting unnecessarily, the main point was "please release often, the users would be very thankful, and they do not care as much about version numbering and api changes, and contexts, as you do". so if you release now, and then do a bugfix release by changing the context like cmlenz suggests, who would care? and then release something further developped with maybe an idea of cboos in it discussed? i sometimes think you greatly underestimate the appreciation people have for this piece of software called trac, now, even if it might be not perfect, but it perfectly does its job. rupert. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
