I love the idea of a git mirror, as for versioning if someone said to me version 10, 11, 12 I'd assume major differences between them, if someone said 1.0, 1.1, 1.2 I'd assume minor differences. So for track the 10,11,12 makes more sense to me. I'm looking forward to seeing the up coming changes in how trac is managed and hope to start contributing patches in a few months (once I'm less busy, life just has to make itself get in the way all my fun!). Keep up the good work everyone :)
~Rowan On May 4, 9:40 pm, Christian Boos <[email protected]> wrote: > On 5/4/2010 10:56 AM, mrelbe wrote: > > > Hello Christian and thank you for your apprehensive reply. > > > ... > > > There are a few hints here and there on Trac for newcomers like me, > > but a one-pager on Trac could perhaps be a good idea explaining things > > like when it's ok to take ownership of a ticket though not being part > > of the core team, when it's ok to set a milestone on a ticket, how to > > actually produce patches (this is based on my observation that you > > guys seem to check out the code from SVN, and then use Mercurial > > locally, perhaps making several clones locally to manage your own > > development and to produce accurate patches -- this may be natural to > > many, but not for industry people using commercial VCS...). > > Yes, this is a good idea. We simply need to expand on HowToContribute. > > About the VCS usage, I think it's indeed getting more and more common to > mirror locally a centralized source tree using DVCS tools, for keeping > track of local changes and patches while staying in sync with upstream. > We're going to make that even easier by setting up official git and hg > mirrors (#9235). > > > > > > > I also noticed that milestones 1.0 and 2.0 were removed, and some have > > already commented about the fact that Trac does not denote versions as > > the mainstream does. I would like to make a comment about this. > > > When it comes to introducing tools like Trac to the industry, my > > experience is that the main obstacle is not the product itself; it's > > about confidence in it (maintenance, quality, ... you know). The > > biggest problem I face when I talk to managers in development > > organisations is the fact that the version is 0.x and not 1.x. Now, > > this may seem silly, but since most people are not aware of Trac, even > > less aware of the maturity of Trac, it's quite hard to explain the > > version numbers. I think that this could be overcome by the help of a > > formal statement made on a Trac wiki page, containing pretty much what > > has been stated in this discussion thread. The industry have to get > > used to that each open-source project is driven by its own culture and > > personal interests, which must be handled with care of course. But we > > (which includes myself) should make some effort in explaining this, to > > provide arguments and facts to be used by Trac advocates, like myself, > > when facing presumptive, professional, users. > > I can understand this. Combined with the remark of Itamar that we're > actually using a "shifted" scheme, and the fact that in practice between > us it's common to talk about "version eleven", "version twelve" and more > seldom about "version zero dot eleven", I wonder if we couldn't simply > "unshift", drop the 0. prefix and directly go with the next version as > being version 12? That would at the same quiet down the concerns about > maturity that corporate users could have, yet change nothing in essence > to our actual sequence of major releases (0.10, 0.11, 12.0, 13.0, etc.). > As Noah said, changing that sequence to come suddenly with a "1.0" adds > some connotation of stability of the interface. We simply don't want to > be encumbered with that notion of freeze and the long term maintenance > this could imply. Trac will continue to evolve, and will do so > incrementally. I think that if we would have had a 1.0 version, this > should have been what we called 0.10 and we would now be talking about > releasing 1.2. > > But in the end, it's not *that* important. If we can make Trac > advocates' life easier by picking a release numbering scheme reflecting > more adequately the level of confidence we have in our product (like in, > using major version numbers for our major versions...), I'd personally > be OK to do it. If for some reasons there are resistances to change, I > wouldn't spend much time on this, continuing with 0.13, 0.14, etc. until > the day we feel it would make sense to call it 1.0 also works for me ;-) > > -- Christian > > -- > 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 > athttp://groups.google.com/group/trac-dev?hl=en. -- 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.
