On Oct 10, 2007, at 3:04 PM, [EMAIL PROTECTED] wrote:
> > 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? We do not want to declare some of these APIs as available for public consumption if they are going to break or be removed very shortly. This is why we will not release until the devs are all happy with this new system. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
