On Mon, Feb 14, 2011 at 11:59 PM, Kevin Horn <[email protected]> wrote:
> On the SA list, Mike Bayer made it sound like he's planning on pulling the > 0.7beta off of PyPI for the time being. If that is indeed the case, you > might want to factor that into whatever plan ends up being made. > In that case, we get slightly more time until the next version of 0.7 beta comes out. I'll be surprised if it's more than two weeks, though. On Tue, Feb 15, 2011 at 8:34 AM, [email protected] < [email protected]> wrote: > Both the methods you suggest have been tried before and both have > failed. > So, the solution you're demanding is that we start requiring specific versions, even when those versions may no longer be available on standard PyPI in future? Since that's not actually a viable option, and since our docs already tell people to use our PyPI, unless you can provide another option, we're probably going to have to go with forcing our PyPI. On Tue, Feb 15, 2011 at 8:39 AM, Christophe de Vienne <[email protected]>wrote: > What I do in my own projects is to require SQLAlchemy<0.6.99. This way I > am sure pre-0.7 version don't get installed while bugfix releases on the > 0.6.x branch do. > > And when I get compatible with 0.7.x, then I change the requirement to > <0.7.99. > This is a viable way of specifying the requirements, definitely. I'd actually go with <0.7 and <0.8, though. This way, if version 0.6.99 *does*come out, then you will still get it. 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. > 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. > 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. > 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". -- Michael J. Pedersen My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] -- 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.
