Jacob Kaplan-Moss wrote: > > On Nov 8, 2005, at 10:13 AM, Adrian Holovaty wrote: > >> On 11/8/05, Robert Wittams >> <[EMAIL PROTECTED]> wrote: >> >>> The general feeling from those using or considering Django (including >>> some rubyists) seemed to be "Release a 0.7 tarball, for the love of all >>> that is holy!" >>> >>> It seems that quite some people just aren't comfortable with checking >>> things out of subversion. They don't particularly want backwards >>> compatibility, just a tarball. This would probably widen the number of >>> people willing to use/try out Django. >>> >> >> If all this means is automatically packaging a tarball every couple of >> days/weeks, let's do it. > > > I think we need to bite our lips, suck it up, and release a 1.0 > version. It seems that we keep running into feeping-creaturism every > time we try to set a stake in the ground, and that's limiting > adoption. Obviously everyone is unhappy when their tickets aren't > included, but more tickets are being opened than fixed. I think we > need to accept that certain things might not get done, release a 1.0, > and move on. > > [Calling it "0.7" would inaccurately represent how stable and usable > Django is, which is why I say 1.0.] > > If it sounds OK, I'd like to start a 1.0 release branch and only apply > any outstanding bug fixes to it; moving feature requests/ patches to a > 1.1 target. That way we can get a stable 1.0 out the door and focus on > 1.1 for feature improvements. > > In terms of backwards-compatibility, it seems most of the big deal > architectural changes have already been done, and as long as we provide > VERY EASY upgrade paths from 1.0 -> 1.x I think we're OK. > > So, any objections to starting a 1.0 bug-fix-only release branch? > > Jacob >
Ok, so this generated quite a bit of traffic. I *really* don't think that 1.0 should be considered on the basis of stability and usability of the implementation. It should be on the basis of "is this a reasonable base to offer backwards compatibility for", ie how much do we *know* is going to have to change. These are the things that definitely need to happen before we end up with a commitment to back compat nightmares: 1) Get rid of core fields * ( this blocks a surprising amount of stuff). 2) Sort out whether magic model modules are really a good idea. Adrian was talking about this, I also talked to Simon about this yesterday at the meetup. I am in favour of getting rid of them. 3) Some kind of story on authorisation that works for people other than newspapers, and isn't an enforced ACL mire. * 4) Transactions 5) Real subtyping as discussed a few weeks ago * 6) Proper schema checkpointing and transitioning * 7) Extract the admin history thing from manipulators into a seperate app* I was planning to do the * items in a branch before 1.0, with the explicit aim of doing every breaking change in one lump before 1.0 so as to minimise the number of times people have to mess with their models. The reason I haven't done any of these yet is because new-admin is supposed to be backwards compatible model wise. I could change this, but it makes checking for regressions much harder. I have no idea why we have to marry the idea of releasing a tarball to the number 1.0, but the number 1.0 is already explicitly married to backwards compatibility in the eyes of most users. IMO there are still a number of areas that need a fair amount of work. I would be much happier just releasing a tarball with no guarantees. I'd even be happier about releasing nothing than rushing 1.0. This is exactly the scenario I'd hoped to avoid with my message, emphasising that right now, people seem far more concerned about just having a tarball out there than they do about version numbers or backwards compatibility. So when we say "release a 1.0, and move on.", we are IMO making an explicit back compat commitment, and so moving on is just what we will be precluding. ------------------ As to the state of new-admin at the moment, it is fairly complete functionality wise, and stability wise I do not believe it is significantly worse than trunk. I do still have a very small number of bits to templatise - date_hierarchy in the change_lists being the main offender. I'm still not satisfied with the api of auto generated forms - there is some duplication between formfieldwrappers and the tower of bound classes. I think that I will leave this to stew for a while, and fix it properly in the backwards incompatible branch - I have a feeling the clean solution to this may rely on getting rid of core fields. This is why I have not documented it at all in NewAdminChanges.
