Hi Tim,
On 11/25/2016 11:49 AM, Tim Graham wrote:
> After doing releases about once a month for a while, I'm thinking it
> would be nice if releasing Django could be a bit more automated. As far
> as I know, the process hasn't changed too much in 10 years, while the
> state of Python packaging has
Appreciate the security concerns of the jenkins boxes, but Jenkins is the
obvious choice as a task runner. My first thought would be to bring up a
special slave that was particularly hardened and walled off from the
regular PR runners. I'm unsure how far access to the slave from the master
coul
I agree that most of the workflow could be scripted.
The manual verification step for checksums exists because there was an error in
checksums once in the distant past and we took some flak for that. Since you’re
making releases regularly, you’re much less likely to make a mistake. A script
(ho
Hi,
+1 to automating as much as possible; one thing though: Personally I do not
like uploading via Jenkins as a security issue there might compromise our
PyPi account. This is especially important if a build slave where able to
do something to the master… So I think as first step it would be ni
I'm pretty confident we can just automate the process you currently do.
On 26 November 2016 at 05:40, Josh Smeaton wrote:
> I think automating as much of the release process is a fantastic idea.
> Regarding bumping the release numbers, have you seen the bumpversion
> project https://pypi.python.
I think automating as much of the release process is a fantastic idea.
Regarding bumping the release numbers, have you seen the bumpversion
project https://pypi.python.org/pypi/bumpversion?
After some trial and error, I seem to have a configuration that works with
the existing version tuple in
On Fri, 25 Nov 2016 11:49:54 -0800 (PST)
Tim Graham wrote:
> After doing releases about once a month for a while, I'm thinking it would
> be nice if releasing Django could be a bit more automated. As far as I
> know, the process hasn't changed too much in 10 years, while the state of
> Python
On Fri, Nov 25, 2016 at 8:49 PM, Tim Graham wrote:
> After doing releases about once a month for a while, I'm thinking it would
> be nice if releasing Django could be a bit more automated. As far as I
> know, the process hasn't changed too much in 10 years, while the state of
> Python packaging h
After doing releases about once a month for a while, I'm thinking it would
be nice if releasing Django could be a bit more automated. As far as I
know, the process hasn't changed too much in 10 years, while the state of
Python packaging has improved.
Currently doing a release requires bumping t
Today the Django team issued 1.9.2 as part of our security process. This
releases address a security issue, and we encourage all users to upgrade as
soon as possible.
The Django 1.8.9 release fixes several bugs in 1.8.8 but no security issues
as the issue fixed in 1.9.2 doesn't affect older ver
I hope anyone who still cares about these versions has their own copy…
--
Aymeric.
> On 17 nov. 2015, at 17:46, Tim Graham wrote:
>
> I wonder if anyone objects to removing some non-trivial logic to support old
> download redirect URLs:
>
> https://github.com/django/djangoproject.com/pull/
I wonder if anyone objects to removing some non-trivial logic to support
old download redirect URLs:
https://github.com/django/djangoproject.com/pull/548
This only affects the redirect URLs like /download/%(version)s/tarball/. The
files are still accessible at their actual URLs like
https://ww
About "release early, release often". If the core team would release
often the would spend more time merging bugfixes to several version
branches than actually doing the great stuff that they do to django.
Come on guys, we dont need releases. We are webdevelopers and the web
changes everyday.
--~
Hi all --
It's apparent from the recent blog and list activity that some members of the
Django community feel that we've screwed up in waiting so long to make another
release; some have started to despair that we'll ever ship 1.0. This uncertainty
has been confounded by our failure to be more tra
Get over it. No one writes a blog post as the first crack at a
problem. He's brought the stuff up before and did not meet with
satisfaction. For the record, I can't stand the passive-aggresiveness
of attacking someones honest attempt at criticism just because it
didn't enter the channel you des
On Mon, Jun 9, 2008 at 3:57 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> As mentioned in my previous post, if it's indeed three months, I agree,
> but if it's only "hopefully" three months, then do we want to end up six
> or nine months out still waiting for 1.0 to land "in a couple months?"
We
On Wed, Jun 11, 2008 at 12:18 AM, Peter Melvyn <[EMAIL PROTECTED]> wrote:
>
> On 6/9/08, Ian Kelly <[EMAIL PROTECTED]> wrote:
>
>> I don't know why this is so mysterious. A small amount of browsing
>> turns up that the code was added in revision [4916] and specifically
>> enabled for Oracle on
On 6/9/08, Ian Kelly <[EMAIL PROTECTED]> wrote:
> I don't know why this is so mysterious. A small amount of browsing
> turns up that the code was added in revision [4916] and specifically
> enabled for Oracle only to fix ticket #3743.
But it does not explain why ticket #3030 has been closed
On Sat, 07 Jun 2008 18:14:17 -0500, James Bennett wrote:
> On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson
> <[EMAIL PROTECTED]> wrote:
>> I think the most often reason why I've heard is that it takes time to
>> create a release, post it, push security patches to it, etc. Which
>> makes sense, but a
Jacob Kaplan-Moss wrote:
> Wow, this thread keeps on keepin' on, eh?
Wow, starting a reply like that makes you sound like an elitist.
Why not instead say, "There has been a few interesting proposals in
this thread," followed by your impending proposal announcement. You
run a high-profile, popula
(incidentally, for anyone who's joining in and wants to genuinely add
to the discussion: starting your reply by calling one of the
developers a douchebag causes me, at least, to stop listening and
simply assume you're a troll. The more you know...)
--
"Bureaucrat Conrad, you are technically cor
On Tue, Jun 10, 2008 at 12:24 PM, testguy56 <[EMAIL PROTECTED]> wrote:
> Wow, starting a reply like that makes you sound like an elitist douche
> bag.
I love the smell of troll in the morning, don't you?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~--
Jacob Kaplan-Moss wrote:
> Wow, this thread keeps on keepin' on, eh?
Wow, starting a reply like that makes you sound like an elitist douche
bag.
Why not instead say, "There has been a few interesting proposals in
this thread," followed by your impending proposal announcement. You
run a high-prof
On 6/10/08, Eric <[EMAIL PROTECTED]> wrote:
> I'm not certain that this route is perfect, but it seems to be a
> compromise of both worlds.
We use the same approach with mean time redundancy about 1 months.
Peter
--~--~-~--~~~---~--~~
You received this messag
I was in discussions at work on what version to work with on a
enterprise level project with the intent of using 1.0 when it comes
out.
We discussed using 0.96, and tracking trunk. Both routes mean a lot
of maintenance.
If we stay with 0.96, that means that when 1.0 comes out there will be
a lo
Wow, this thread keeps on keepin' on, eh?
So here's the deal. The core developers have always had a vague idea
about what would be in 1.0 and when it would be released, but it's
apparent we've not been formal enough about that plan. To wit, many
folks are complaining about a lack of a feature lis
Le 10 juin 08 à 03:16, Karen Tracey a écrit :
> I'd trade your controversial part for an alternative: merge mewforms-
> admin back to trunk now.
+1 if involved people in this branch agree (I hadn't found the time to
test it yet...).
> I think it's a shame newforms-admin wasn't done in a fash
+1. For my purposes, newforms-admin *is* trunk.
On Mon, Jun 9, 2008 at 9:16 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss <
> [EMAIL PROTECTED]> wrote:
>
>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and t
> I'd trade your controversial part for an alternative: merge mewforms-admin
> back to trunk now. It's been as 'usable' as old admin for months. Sure,
> it's got a couple of dozen 'blocking' bugs in the tracker but none of them
> are all that serious. Current admin, as you note, also has some b
And I would also organise a sprint 3-4 weeks after the merge dedicated
to fixing bugs in NFA.
On Jun 10, 7:40 pm, Julien <[EMAIL PROTECTED]> wrote:
> +1 for merging newforms-admin ASAP.
>
> On Jun 10, 7:13 pm, "Gábor Farkas" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jun 9, 2008 at 11:02 PM, Adrian
+1 for merging newforms-admin ASAP.
On Jun 10, 7:13 pm, "Gábor Farkas" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 9, 2008 at 11:02 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
> > <[EMAIL PROTECTED]> wrote:
> >> * Start a "train release" sch
On Mon, Jun 9, 2008 at 11:02 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and then a final release. Features that are done by
>
> I'd trade your controversial part for an alternative: merge mewforms-admin
> back to trunk now. It's been as 'usable' as old admin for months. Sure,
> it's got a couple of dozen 'blocking' bugs in the tracker but none of them
> are all that serious. Current admin, as you note, also has some
Am 10.06.2008 um 03:16 schrieb Karen Tracey:
> I'd trade your controversial part for an alternative: merge mewforms-
> admin back to trunk now. It's been as 'usable' as old admin for
> months. Sure, it's got a couple of dozen 'blocking' bugs in the
> tracker but none of them are all that serious
Am 10.06.2008 um 03:16 schrieb Karen Tracey:
> I'd trade your controversial part for an alternative: merge mewforms-
> admin back to trunk now. It's been as 'usable' as old admin for
> months. Sure, it's got a couple of dozen 'blocking' bugs in the
> tracker but none of them are all that se
On Mon, 2008-06-09 at 21:16 -0400, Karen Tracey wrote:
> On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0
> betas, a
> rc or two, and then a final release. Features that are done by
On Mon, 2008-06-09 at 21:16 -0400, Karen Tracey wrote:
> On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0
> betas, a
> rc or two, and then a final release. Features that are done by
On Jun 9, 2008, at 9:16 PM, Karen Tracey wrote:
> I'd trade your controversial part for an alternative: merge mewforms-
> admin back to trunk now. It's been as 'usable' as old admin for
> months. Sure, it's got a couple of dozen 'blocking' bugs in the
> tracker but none of them are all th
On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss <
[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive b
Personally I loosely follow trunk so I'm not waiting for 1.0, and I
don't really care how many "releases" there are between now and 1.0.
What I would like to see is the last few major NFA blockers fixed and
NFA merged into trunk. Just get it out there in trunk, so we can get
more real world use re
Yes, we will have problem. And we will not port our apps to 1.0.
I'm in the same situation. And I know we'll never go for 1.0 when it
will be ready, because there will be too much work to port all the
applications through unicode, qs-rf and nfa changes. We will stay with
0.96 until customer drops
On Mon, Jun 9, 2008 at 2:07 AM, Peter Melvyn <[EMAIL PROTECTED]> wrote:
> On 6/9/08, James Bennett <[EMAIL PROTECTED]> wrote:
>
>> So please, in all honesty, tell me why you think Django's development
>> process isn't "visible" enough for people who are concerned and want
>> to get information.
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive bu
Hi, all.
On Mon, Jun 9, 2008 at 1:35 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 2008-06-09 at 15:28 -0500, James Bennett wrote:
>> On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <[EMAIL PROTECTED]>
>> wrote:
>> > I agree with the sentiment of this, but we've passed the point where
Apologies for posting before I finished reading.
On Mon, 2008-06-09 at 15:28 -0500, James Bennett wrote:
> On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> > I agree with the sentiment of this, but we've passed the point where
> > it's a useful argument.
>
> I'll conced
On Mon, 2008-06-09 at 15:28 -0500, James Bennett wrote:
> On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <[EMAIL PROTECTED]>
> wrote:
> > I agree with the sentiment of this, but we've passed the point where
> > it's a useful argument.
>
> I'll concede that if you'll concede that we've also passed
On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
> I agree with the sentiment of this, but we've passed the point where
> it's a useful argument.
I'll concede that if you'll concede that we've also passed the point
where issuing interim pre-1.0 releases offers any real gai
On Mon, 2008-06-09 at 14:08 -0500, James Bennett wrote:
> There would be frustration from people who want to stick to, say, the
> hypothetical 0.98 but need a third-party app that forges ahead to the
> hypothetical 0.99. There would be gnashing of teeth from people who
> would hear that they need
On Sat, 2008-06-07 at 12:06 -0700, Jacob Kaplan-Moss wrote:
> For the record, and if the author of this blog post is reading: I
> can't stand the passive-aggressiveness of making a rant on your blog
> and waiting for us to read it. I wish this had been brought up here
> instead of trying to drum
On Mon, Jun 9, 2008 at 1:09 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Posting this here rather than someone's blog post comments:
Rob, let me step back a moment and point out how this comment would
strike me if I didn't know you and didn't know that it wasn't your
inention to come off this w
I think that it is better way to write code and produce 1.0 as soon as
possible then to write tons of text that doesn't help in it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
Posting this here rather than someone's blog post comments:
Just a note up front, Django has completely changed the way I build
websites and I'm totally enamored with it, but I'm trying to think of
how official releases could have benefitted myself in my situation and
this is what I came up with.
On Mon, Jun 9, 2008 at 11:54 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I believe it's one official release back. James will know better.
For security we patch trunk, of course, as well as current stable
release plus the two previous releases. This means we currently
provide security updates
On Mon, Jun 9, 2008 at 11:37 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
...
> When our projects are done, they're done.
Ah, that's a foreign concept to me. In that case, yeah, your strategy
sounds good. :)
...
> Please tell me more about the legacy problem you are predicting.
>
Our projects ar
On 6/7/08, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > Where I work we use 0.96 (though I use trunk on my personal projects).
> > We use 0.96 because we have up to 12 separate Django projects
> > rotating through at a time
Hi all,
What I have been missing in this discussion is the definition of a
release. It is important to release in the right manner, so that it
is worth while to spend time on it.
A release could be:
1/ a tag on a specific svn version
2/ a tag on a specific svn version and accompanying branch i
> I'm really, honestly baffled by this statement. Django development
> happens in the open. Always has. Anyone anywhere at any time can look
> at what's going on, see what the dev team is talking about, etc. And
> it's not like the places where the discussion happen are a super top
> secret; a l
On 9 jun, 05:00, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 8, 2008 at 9:51 PM, Ashish <[EMAIL PROTECTED]> wrote:
> > my proposal is
>
> You do know that a list of what has to happen before 1.0, and a page
> listing the status of each item, has been available for quite some
> time
On Mon, Jun 9, 2008 at 1:50 AM, Ashish <[EMAIL PROTECTED]> wrote:
> In short all I am looking for is commitment to " freezing the scope,
> publishing a plan and hitting it for 1.0 " That will greatly increase
> the community's trust.
Er. You linked to a well-known thread in which the plan for 1.
On 6/9/08, James Bennett <[EMAIL PROTECTED]> wrote:
> So please, in all honesty, tell me why you think Django's development
> process isn't "visible" enough for people who are concerned and want
> to get information.
I give you example: few weeks ago I discovered that problem #3030
still per
I have read threads on 1.0 , some one more than an year old and some
very recent. I see exactly same issues being discussed. 1.0 has been
discussed for way too long. Get past it.
Thats why I proposed "publishing a plan and freezing the scope and
hitting it. " see details on earlier post in this
On Sun, Jun 8, 2008 at 9:51 PM, Ashish <[EMAIL PROTECTED]> wrote:
> my proposal is
You do know that a list of what has to happen before 1.0, and a page
listing the status of each item, has been available for quite some
time, right? I
> Lack of visibility on what is going on with 1.0 and over an
my proposal is
1) core developers decide an absolute minimum features that needs to
be implemented to get to 1.0 rc and FREEZE it. Push all other features
out beyond 1.0. Ignore any other requests.
2) Focus on only those features and any critical bugs.
3) Between 1.0 rc and 1.0 final/ga do only b
Am 08.06.2008 um 22:10 schrieb Andrew Durdin:
> Speaking of sprints, are there any plans to hold a Django sprint
> during Europython 2008 (only one month away now)?
I added Django to the Sprint Suggestions page in the Europython wiki
[1] some time ago and remember Jacob agreeing that it's a g
Release an interim version because 0.96 is getting stale.
Leave newforms admin out because its taking forever.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send em
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Wait for newforms-admin to be done, merge it, and release 1.0 (well,
> a series of beta/rcs, then final). This has been "plan A" all along.
+1; this is The Right Thing.
> * Release an interim release right away to r
lopment.
> We don't have the resources to continuously update all of them to
> trunk and fix the various backward incompatible changes that might
> crop up, and each one can't be on its own trunk release or trying to
> assemble any sort of library would be a nightmare. Not even
>
The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0. If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.
I think this is
> That aside, now that QSRF is
> getting a real fleshing-out and all these reports are trickling in, I
> think it would be a bad idea to stamp a version right now until either
> someone can step up and fill Malcolm's shoes as a queryset maintainer,
> or he becomes available once again from
On Jun 8, 9:27 am, Wim Feijen <[EMAIL PROTECTED]> wrote:
> My vote is +1, because I think Django needs another stable release
> right now. Fortunately, the trunk is stable (thank you!). Rob says
> that it is good for a software project to have regular releases on a
> half-year basis and I totally
On Jun 8, 2008, at 4:27 AM, Wim Feijen wrote:
> Fortunately, the trunk is stable (thank you!).
I think what people are missing most here is that this statement is
moderately inaccurate. Since QSRF, there have been a significant
number of data-fetching related tickets that are relatively ea
James Bennett wrote:
> If that means organizing a sprint or two on it
> and then doing a trunk merge to get more eyeballs on the code, then
> let's do that instead.
+1 for early merging. Merging qs-rf helped (forced :-) ) many people to
catch many bugs that won't ever be found on the branch due
Jacob, I am very glad this discussion is being held, and with such
good arguments.
My vote is +1, because I think Django needs another stable release
right now. Fortunately, the trunk is stable (thank you!). Rob says
that it is good for a software project to have regular releases on a
half-year b
For the record, I'm -1 on releasing 1.0 without NFA.
As I've discussed with Jacob and Adrian, GeoDjango will be merged with
trunk at some point in the future. In my opinion, there's nothing
preventing it from being included in the 1.0 release (I'm currently
addressing the biggest hurdle, documen
On Sun, Jun 8, 2008 at 3:06 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive
Hi, all.
On Sat, Jun 7, 2008 at 9:38 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> And for the record, I do think that *post-1.0* we should do more
> frequent releases, because it'll be quite a bit simpler to do at that
> point. I just think that right now it's not really worth the trouble;
>
On Sat, Jun 7, 2008 at 6:17 PM, James Bennett <[EMAIL PROTECTED]> wrote:
...
> Newforms-admin needs to get done. ... If that means organizing a sprint or
> two on it
> and then doing a trunk merge to get more eyeballs on the code, then
> let's do that instead.
As someone who would benefit from N
On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
...
> Where I work we use 0.96 (though I use trunk on my personal projects).
> We use 0.96 because we have up to 12 separate Django projects
> rotating through at a time
In that environment, perhaps you should work on tools an
And for the record, I do think that *post-1.0* we should do more
frequent releases, because it'll be quite a bit simpler to do at that
point. I just think that right now it's not really worth the trouble;
the same people who currently complain that they have to use a
packaged release but want a po
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin a
> Newforms-admin needs to get done. Putting it off from the first couple
> betas or RCs will just increase the temptation to put it off further,
> so what we should do is identify anything that's slowing it down and
> work to resolve that. If that means organizing a sprint or two on it
> and then
On Jun 7, 5:17 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Newforms-admin needs to get done. Putting it off from the first couple
> betas or RCs will just increase the temptation to put it off further,
> so what we should do is identify anything that's slowing it down and
> work to resolve th
sort of library would be a nightmare. Not even
mentioning having to support various Django releases on our production
servers. So we're stuck on 0.96 until 1.0 comes along.
Not so much a tough call to pick 0.96 in our case, but I'm jealous at
the
>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and then a final release. Features that are done by the
>> dates get released, those that aren't, don't. Make these dates
>> aggressive but not crazy. And -- here's the controversial part -- make
>> newforms-adm
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive bu
On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I think the most often reason why I've heard is that it takes time to
> create a release, post it, push security patches to it, etc. Which
> makes sense, but at the same time there are a lot of valid points in
> the blog pos
I think one of the best points this article raises is that as long as
a large number of people are using trunk this forces us to be way more
careful about backwards compatibility, and I think that often times
gets in the way of getting things done. One suggestion that I have
heard is that every f
On Jun 7, 2008, at 1:06 PM, Jacob Kaplan-Moss wrote:
>
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- h
(... apologies if this message doesn't end up in the right thread, I had
to cut'n'paste everything to get the original message in here -
hopefully with the correct headers)
Jacob Kaplan-Moss wrote:
> For the record, and if the author of this blog post is reading: I
> can't stand the passive-agg
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin an
On Sat, Jun 7, 2008 at 12:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive b
For the record, and if the author of this blog post is reading: I
can't stand the passive-aggressiveness of making a rant on your blog
and waiting for us to read it. I wish this had been brought up here
instead of trying to drum of some supposed "outcry" for a new release.
That said, he's got a v
I'm pretty sure its been stated several times on the board but there will be
no versions released between .96 and 1.0.
On Sat, Jun 7, 2008 at 12:48 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Regarding this blog post:
> http://www.technobabble.dk/2008/jun/07/django-importance-releases/
>
> I th
Regarding this blog post:
http://www.technobabble.dk/2008/jun/07/django-importance-releases/
I think the most often reason why I've heard is that it takes time to
create a release, post it, push security patches to it, etc. Which
makes sense, but at the same time there are a lot of valid points
94 matches
Mail list logo
