SVN Milestones
David Cramer
E.g. a .97 release, or .96.2 or something. It would make things a lot
more sane to know where you're at, as everyones using SVN now, but SVN
changes so much from X revision to Y revision that there really needs
to be tagged releases.
Justin Lilly
Jeremy Dunck
I keep a ForeignTimeline wiki page where I reference which rev of
Django I'm on. When I move up, I just pick a target revision largely
by balancing which features I want with the pain of
BackwardsIncompatibleChanges since my last up.
Or are you talking about trying to discuss Django with other people
running on different revs? If *thats* the problem, maybe IRC nicks
should start including SVN revs. ;-)
alex....@gmail.com
tickets needed for merges of nfa and qs-rf, which is a better system
then having variuos tags :P
On Apr 16, 6:58 pm, "Jeremy Dunck" <jdu...@gmail.com> wrote:
Adrian Holovaty
> Can we start setting some milestones so SVN stops being SVN :)
>
> E.g. a .97 release, or .96.2 or something.
My preference would be to finish up newforms-admin and
queryset-refactor, then release a 1.0 beta. Given that SVN has a
number of tricky/backwards-incompatible changes (everything-Unicode
and template auto-escaping), it'd be less of a hassle in the long term
if we included all of those changes in one big release.
Adrian
--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com
alex....@gmail.com
track of tickets for the milestones of merging qs-rf and nfa(and those
are deffinately milestones) would be very handy, right now in order to
follow those one needs to play around with keywords(for example qs-rf
tickets are taggged qs-rf, except for ones that are fixed, which are
tagged qs-rf-fixed), this quickly becomes difficsult to track, post qs-
rf, nfa it would also be helpful to track 1.0 tickets(those referenced
on the VersionOneFeatures wiki page. Just my thoughts.
On Apr 18, 11:59 am, "Adrian Holovaty" <holov...@gmail.com> wrote:
David Cramer
because .96 is so old, and trunk is so vast. Many people use trunk,
but don't update continuously (as it is trunk after all). So you end
up with a bunch of people in the midst of "why doesn't this work", or
"why is it clean_data?" :)
On Apr 18, 10:50 am, "alex.gay...@gmail.com" <alex.gay...@gmail.com>
wrote:
ydjango
commercial product based on a beta framework.
How long do you expect to remain in beta?
Is there a reason you cannot call it just 1.0
thanks
Ashish
On Apr 18, 9:59 am, "Adrian Holovaty" <holov...@gmail.com> wrote:
James Bennett
> Is there a reason you cannot call it just 1.0
So would you prefer to have a beta-quality product whose developers
lie and call it 1.0?
The next version of Django to be released will be 1.0. It will most
likely be preceded by several beta and/or RC releases for testing and
final shakedown. At this point no-one can truthfully give a date for
when either of those will happen, and no-one can truthfully state in
advance how many beta and/or RC releases will precede 1.0 final.
If you can't live with that, I'm sorry, but there's no way it can be changed.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Kenneth Gonsalves
On 19-Apr-08, at 8:52 PM, James Bennett wrote:
> On Sat, Apr 19, 2008 at 10:17 AM, ydjango <neera...@gmail.com>
> wrote:
>> Is there a reason you cannot call it just 1.0
>
> So would you prefer to have a beta-quality product whose developers
> lie and call it 1.0?
I wouldn't even call the current svn head a beta-quality product
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/code/
Steve Holden
> On 19-Apr-08, at 8:52 PM, James Bennett wrote:
>
>
>> On Sat, Apr 19, 2008 at 10:17 AM, ydjango <neera...@gmail.com>
>> wrote:
>>
>>> Is there a reason you cannot call it just 1.0
>>>
>> So would you prefer to have a beta-quality product whose developers
>> lie and call it 1.0?
>>
>
> I wouldn't even call the current svn head a beta-quality product
>
>
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Kenneth Gonsalves
On 20-Apr-08, at 12:47 AM, Steve Holden wrote:
>> I wouldn't even call the current svn head a beta-quality product
>>
>>
> Which is probably why it isn't yet a beta release?
what I meant is that it is stable and production ready and that it is
time people stopped evaluating products by looking at the version
numbers
Steve Holden
> On 20-Apr-08, at 12:47 AM, Steve Holden wrote:
>
>>> I wouldn't even call the current svn head a beta-quality product
>>>
>>>
>> Which is probably why it isn't yet a beta release?
>>
>
> what I meant is that it is stable and production ready and that it is
> time people stopped evaluating products by looking at the version
> numbers
>
soon now" comes in.
I don't think it's unreasonable of people to wait until there is an
announcement of future stability, which is effectively what 1.0 will
represent. At the moment I would agree that (even) more people could
probably use the trunk version for production systems, but it's human
nature for some people to crave stability and want to avoid changing
code to keep in step with current versions, so they stay away from
Django because they know that /something/ is due to change, though they
may not know the details of newforms admin or queryset refactoring.
We can probably agree that the sooner 1.0 comes out the better it will
be for Django takeup, but that doesn't mean a compromise on quality is
acceptable.
jo...@szakmeister.net
> We have one. Its called 1.0 and the more you contribute, the closer you get
> ;)
with what he thinks is left for a 1.0 beta, but I can't find anything
on the site stating that. Django isn't using the roadmap feature of
Trac to organize the milestones, which is a great mechanism to
indicate what needs to get done for a particular release. Are you
using the version field for that? As far as I can see, here's the
breakdown:
SVN - 781 tickets
newforms-admin - 93 tickets
queryset-refactor - 5 tickets
Does *all* of that need to get done for 1.0? What helps achieve 1.0
the quickest? I'd love to help, but every time I come to contribute
my time I have no idea where Django is heading... and the lack of a
clear goal for release is one reason why. This ultimately translates
into "I'm not spending my time here." I don't have a lot of time to
spend (and I'm sure that's true of many folks working on Django), but
when I do spend it, I want to make sure it's getting a project closer
to release. And in this particular case, I want to help Django get to
1.0.
And yes, I know trunk is pretty darn stable... but the thing I'm after
is no more painful API changes. :-)
-John
Malcolm Tredinnick
On Wed, 2008-04-23 at 03:40 -0700, jo...@szakmeister.net wrote:
> On Apr 16, 7:56 pm, "Justin Lilly" <justinli...@gmail.com> wrote:
> > We have one. Its called 1.0 and the more you contribute, the closer you get
> > ;)
>
> No offense, but where is that milestone documented? Adrian chimed in
> with what he thinks is left for a 1.0 beta, but I can't find anything
> on the site stating that.
Most of the discussion and conclusions are done on this mailing list.
However http://code.djangoproject.com/wiki/VersionOneFeatures is a
reasonable list. However, it has grown a bit into a wishlist, rather
than a feature set, so we might have to reign things in a bit there to
make it clear what are the real pre-1.0 blockers.
Roughly, newforms-admin, queryset-refactor, model-aware validation,
comments replacement (although that's a little up in the air now that
it's been accepted as a SoC project, since 1.0 would hopefully be out
long before SoC is done), docs refactoring and INSTALLED_APPLICATIONS
refactoring were the main features for 1.0.
Of those, queryset-refactor, model-aware validation and docs refactor
are "mostly done". So it's getting close.
Add in fixing as many other bugs as possible and a few of other general
areas, but they're "nice to have", rather than being a showstopper.
> Django isn't using the roadmap feature of
> Trac to organize the milestones, which is a great mechanism to
> indicate what needs to get done for a particular release.
Sometimes. However, we're only getting to the point now where it would
really be practical to assign a 1.0 milestone (really 1.0-blocker
status) to anything.
> Are you
> using the version field for that?
No, the version field is the version against which the problem is
reported.
> As far as I can see, here's the
> breakdown:
> SVN - 781 tickets
> newforms-admin - 93 tickets
> queryset-refactor - 5 tickets
>
> Does *all* of that need to get done for 1.0?
Of course not. Not every ticket represents a bug, for a start, and it's
not only bugs that are blockers.
> I don't have a lot of time to
> spend (and I'm sure that's true of many folks working on Django), but
> when I do spend it, I want to make sure it's getting a project closer
> to release. And in this particular case, I want to help Django get to
> 1.0.
That's a fair enough comment.
I'll make some time to do a pass through the VersionOneFeatures list and
rationalise things a bit. We can start pulling together a list of
tickets that are absolute blockers, too (I gather James already had some
of that stuff written down somewhere). The trick there is keeping the
list somewhat managed and not suffering form everybody adding pet
features. It's something the release manager should probably own.
To a large extent, though, a lot of the blockers are the big features
mentioned above. Newforms-admin would be one are to devote testing, bug
triaging and patch writing. INSTALLED_APPS is Adrian's baby and I don't
know what his current thinking is there; maybe he can offer some
guidance about whether help is needed.
Regards,Malcolm
--
The early bird may get the worm, but the second mouse gets the cheese.
http://www.pointy-stick.com/blog/
Kenneth Gonsalves
--
ydjango
how do we know we got there when we get there.
and defining roadmap from current pre-beta stage to 1.0.
what is there on wiki currently is outdated and not well thought of
and not clear.
Thanks Malcom for taking the lead.
thanks
Ashish
On Apr 23, 3:58 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> > On Apr 16, 7:56 pm, "Justin Lilly" <justinli...@gmail.com> wrote:
> > > We have one. Its called 1.0 and the more you contribute, the closer you get
> > > ;)
>
> > No offense, but where is that milestone documented? Adrian chimed in
> > with what he thinks is left for a 1.0 beta, but I can't find anything
> > on the site stating that.
>
> Most of the discussion and conclusions are done on this mailing list.
John Szakmeister
<mal...@pointy-stick.com> wrote:
[snip]
Thanks for answers to the questions Malcolm!
> > I don't have a lot of time to
> > spend (and I'm sure that's true of many folks working on Django), but
> > when I do spend it, I want to make sure it's getting a project closer
> > to release. And in this particular case, I want to help Django get to
> > 1.0.
>
> That's a fair enough comment.
>
> I'll make some time to do a pass through the VersionOneFeatures list and
> rationalise things a bit. We can start pulling together a list of
> tickets that are absolute blockers, too (I gather James already had some
> of that stuff written down somewhere). The trick there is keeping the
> list somewhat managed and not suffering form everybody adding pet
> features. It's something the release manager should probably own.
Definitely. Managing feature creep is always tough.
> To a large extent, though, a lot of the blockers are the big features
> mentioned above. Newforms-admin would be one are to devote testing, bug
> triaging and patch writing. INSTALLED_APPS is Adrian's baby and I don't
> know what his current thinking is there; maybe he can offer some
> guidance about whether help is needed.
Thanks for the guidance. It looks like there might be a couple of
other things to poke around at, so perhaps I'll start there.
-John
James Bennett
<mal...@pointy-stick.com> wrote:
> I'll make some time to do a pass through the VersionOneFeatures list and
> rationalise things a bit. We can start pulling together a list of
> tickets that are absolute blockers, too (I gather James already had some
> of that stuff written down somewhere). The trick there is keeping the
> list somewhat managed and not suffering form everybody adding pet
> features. It's something the release manager should probably own.
I do have a list. I've been wary of publishing it because this sort of
thing inevitably turns into a festival of people posting things that
are important to *them* but not necessarily important to Django as a
whole, and assuming that a refusal to put them on a "1.0 feature list"
represents the utter failure of Django as a project.
So. Keep three things in mind as you read this:
1. This is not a comprehensive list of every single thing that'll
happen before 1.0; this is merely a list of the most important
things that need to happen before I'd feel comfortable calling
anything "Django 1.0".
2. My criteria for this list involve a combination of things that are
huge and universally agreed to be important; things that -- though
they may be minor or isolated -- make it noticeably easier to use
Django in a common situation; and things that, while less
important, involve backwards-incompatible changes and so need to
happen before we slap a seal of compatibility on 1.0.
3. Unless you have a commit bit or I'd recognize your name from your
contributions to Django, don't take this as an invitation to pitch
your pet feature. I'm not trying to be mean here, but there are
lots of things that simply aren't requirements -- for the project
as a whole -- to get to 1.0, and which can sensibly be dealt with,
in incremental fashion, at a later time. As such, I naturally pay a
lot more attention to people who've demonstrated their
understanding of the big picture.
So here goes.
First up, the big things:
* Queryset-refactor
* Newforms-admin
* Model-level validation
* Anything in Django still using oldforms -> uses newforms
These just flat-out have to happen, and represent major
work. Fortunately, there are already people doing the work and I
believe at least three of the four are getting really close.
Then there are things which, while more self-contained, contribute
significant improvements in common use cases, and which should happen
before 1.0. If you're looking for something to work on and you know
Django's codebase, this would be the list you want to look at.
* Marty's file backend work needs to land, because that drastically
improves both the ease of file handling in general and the ability
to use popular storage solutions like Amazon S3.
* The refactoring of Django's dispatcher. Jacob and, I believe, Jeremy
have been working on this, and it's key because right now signals
are incredibly useful but dog-ass slow.
* WSGI fixes, particularly for SCRIPT_NAME. Yeah, there's a common
pattern people use to work around it, but we should knock this out
before 1.0; we already solved the problem of building a full URL for
relative redirects, so we should be able to solve this too.
* The template tag loading mechanism needs to get fixed; it's the last
bit of arguable "magic" in Django, and the number of times now that
I've seen people angrily trying to work out why we look in
"django.templatetags" indicates that it's causing
headaches.
* Reverse URL resolution needs some love, because right now there are
all kinds of not-too-complex regular expressions that it'll choke
on. And since reverse resolution is one of the keys to portable,
reusable code, we need to get that cleaned up.
* The way django.template.Variable does resolution needs to take
filters into account, so that tags which use it can be passed
variables with filter expressions and work properly.
Then there are some backwards-incompatible things which, while not as
big, need to happen. These are going to need an experienced person
banging out the design and then coding it up:
* The oft-proposed INSTALLED_APPS refactoring needs to happen, so that
things like re-using an app multiple times in the same Django
instance will be easy and the hackiness of app_label will go away.
* The mechanism for specifying and ordering middleware needs to be
reworked, so that some of the nastier situations people can get into
with figuring out what order to put their middleware in (and some
situations where there's simply no possible ordering that works)
will go away.
And that's my list. Twelve things which, for one reason or another,
need to happen before we roll a 1.0 release. Again, that doesn't mean
we'll ignore all other work before 1.0, just that these are the really
important things that have to happen.
And as a pre-emptive note because someone will notice and point it
out: yes, there are a couple things that aren't on this list that some
folks probably think should be, including:
* Refactoring django.contrib.comments
* Jacob's documentation refactor
* ORM aggregation support
Of these three, only one is arguably backwards incompatible, and
that's the comment refactor. But it's been proposed as a Summer of
Code project, and fortunately it's fairly easy to deal with
replacement of a contrib app: we can simply freeze the old one (or,
better, find someone interested in maintaining it) and make it
available for as long as there's interest.
The other two don't cause backwards-incompatible changes, and can
basically be rolled out any old time: the docs refactor mostly affects
djangoproject.com rather than development with Django, and the
aggregation proposal is SoC work that can be added in a post-1.0 point
release once it's ready for prime time.
Marty Alchin
> * Marty's file backend work needs to land, because that drastically
> improves both the ease of file handling in general and the ability
> to use popular storage solutions like Amazon S3.
I know you said your list isn't necessarily exhaustive, but I thought
I should pass along a conversation Jacob and I had not too long ago.
He'd like to get Mike Axiak's work on #2070 merged prior to my
filestorage patch, since it's a bit easier to modify mine to work with
his than the other way around. The fix for #2070 looks like it may
have slight backwards-incompatibilities on its own, so it should
probably be considered part of the 1.0 list anyway, but it's
definitely a prerequisite for mine to go in, and since mine's on the
list...
Of course, you guys with the commit bit can hash it out amongst
yourselves as to how you want to do it, I'm fine with it either way. I
just wanted to make sure I made that conversation known, since I don't
think it got passed along to the rest of the crew.
-Gul