On Tue, Feb 15, 2011 at 4:15 PM, Michael Pedersen <[email protected]> wrote: > On Tue, Feb 15, 2011 at 8:44 AM, Alessandro Molina > <[email protected]> wrote: >> >> I have seen that on sf.net there are only 2.0 and master branches. >> How do you plan to handle a branching strategy for future development? > > I'm still somewhat in the air about this, honestly. Right now, I'm thinking > that stable code only will go into master, with development branches > occurring. Been reading "Professional Git", andf I'll admit it's shaping a > lot of my thinking. That doesn't mean it's always right, so I'm keeping > myself open to other ides. >
Stable code related to the "in development version" or "code of stable releases"? As I think that it is usually better to have development code on master and stable releases on their own branches as it makes easier to release patches and fixes for that specific release. >> >> Personally I would suggest to have a branch for each stable release >> where we can just commit fixes. >> Currently we should have something like: >> >> 2.0 >> 2.1 >> 2.2 > > The one major change I would make is that I would not make a 2.2 branch as > yet. Right now, the current order of operations needs to be this: > > Complete migration to sourceforge.net > Release 2.0.4 (we have some minor bugfixes ready for it) > Release 2.1.1 (again, minor bugfixes already ready) > Begin work on 2.2. > Fine, I think that it is a good plan. > >> >> The 2.2 work should probably be based on the percious work to move >> dispatch to crank if we want to procede in that way. I did some work >> on https://bitbucket.org/_amol_/tg-2.2/overview to merge his work with >> the old tip of the TG repository. Let me know if there is any interest >> to move that work on sf.net and I'll migrate it to git. > > Interest? Yes. However, here's where my first significantly unpopular > decision is likely to happen. I don't think we can incorporate those changes > for 2.2. We have way too many issues that need to be resolved. Open bugs in > the code and in the documentation, and a major documentation overhaul, are > all required fixes. Changing the dispatch mechanism again? I don't think I > can get behind that as yet. Our API is too undocumented, too unstable, and > it's causing chaos. Every release, we're deprecating how dispatch happens. > This is not good for our users, and therefore is ultimately not good for us. > > Getting the changes migrated in on their own branch could be a good thing. > However, they would belong off of a proposed updates branch, and not merged > for some time. > Not a problem, it would be better just to have them on sf.net for later inclusion than having them on a forgotten bitbucket project :D >> >> I have a strong feeling that we should enforce a set of stable >> libraries tested with TG. >> Currently the main problem most people have is that if they install TG >> it will work or not depending on the current status of the libraries >> on the PyPI env and we cannot be sure that each library used by TG >> will continue to work with TG. > > Agreed. That's why I'm looking to force the installers to use our private > PyPI as their first repository. It makes us responsible for keeping our > copies of the .egg files current, but that's a small price to pay for being > able to say "easy_install tg.devtools" or "pip install tg.devtools". Great, im my opinion having reliable releases that install flawlessly is fundamental for a framework, especially if you want to capture software development companies interest. -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en.
