1.7 release status (RC2 coming soon)

[Tim Graham]

It's been 2 weeks since the release of 1.7 RC1 and we've seen several bugs opened and fixed, with several still open [1]. We plan to issue a second RC sometime next week if we can empty that list. Help us fix the issues if you have some time and keep testing!

[1] https://code.djangoproject.com/query?status=assigned&status=new&version=!master&severity=Release+blocker&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime

[Tim Graham]

2 weeks later and we still have a fairly strong stream of new bugs (thanks everyone for testing), so I wouldn't expect a second RC until next week at the earliest.

There was a suggestion among the core team to release another RC (even if the list of release blockers isn't zero). This would make testing easier and help us avoid getting duplicate bug reports for issues fixed since RC1, but others were against it: "We should not release RC2 until there are 0 release blockers, though - remember, an RC is supposed to be identical to the final release if there's no blockers." Opinions from the community on that would be welcome.

[Curtis Maloney]

And for those who want to test, remember to use:

    pip install git+https://github.com/django/django.git@stable/1.7.x

to ensure you're testing against 1.7 and not dev :)

--

Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/89fb0487-7828-42e2-a85b-b63be9c28db8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ryan Hiebert]

My opinion is worth less than 2c, but I’m inclined to agree with the dissent.

It seems to me that its easy enough to install the very latest from the github repository versus from a tarball, so leaving RC versions to actually be candidates for release seems like a reasonable idea. Were we releasing prerelease versions on PyPI, then I’d probably reverse that opinion, because at that point it would be easier to install (though only marginally).

Ryan

[Ian Kelly]

On Thu, Jul 24, 2014 at 5:49 PM, Ryan Hiebert <ry...@ryanhiebert.com> wrote:
> My opinion is worth less than 2c, but I’m inclined to agree with the dissent.
>
> It seems to me that its easy enough to install the very latest from the github repository versus from a tarball, so leaving RC versions to actually be candidates for release seems like a reasonable idea. Were we releasing prerelease versions on PyPI, then I’d probably reverse that opinion, because at that point it would be easier to install (though only marginally).

It seems to me that a new release would be useful to have for the
reasons given, but it should be called what it is: a beta version, not
an RC.

[Ryan Hiebert]

> On Jul 25, 2014, at 12:22 AM, Ian Kelly <ian.g...@gmail.com> wrote:
>
> It seems to me that a new release would be useful to have for the
> reasons given, but it should be called what it is: a beta version, not
> an RC.
>

I agree, but I don’t think that releasing a beta after an RC makes good sense either. If there was a really significant benefit to the release, then calling it an RC even though it’s more of a beta seems like a reasonable compromise. I don’t really see a significant benefit to the release over just using latest git branch, though.

[Ian Kelly]

I see two benefits. One is that users who are interested in testing
aren't necessarily going to think to go to github; they're likely to
look for the most recent release and use that (on the other hand, if
they see a beta 4 and an RC 1, they might not necessarily realize the
beta 4 is most recent either, so I take your point). The second
benefit is that the instructions "pull the latest from github" can
*sound* like a lot of work if the user is not a contributor and isn't
experienced with git, and that might deter them from testing.

[Ryan Hiebert]

That makes sense to me. It’s basically the same reasons that a release on PyPI would be helpful: it sounds easier to a newcomer. If there’s consensus on that point (I still think git is pretty easy, but I’ve been using it quite a while), then I’m comfortable with the compromise of the RC nomenclature.

On a somewhat-related tangent, I seem to recall there being a good reason for not releasing pre-release versions on PyPI, but I’m having trouble finding the discussions that document that reason. Anybody care to enlighten me, or give me a link?

[Carl Meyer]

On 07/25/2014 09:17 AM, Ryan Hiebert wrote:
> On a somewhat-related tangent, I seem to recall there being a good
> reason for not releasing pre-release versions on PyPI, but I’m having
> trouble finding the discussions that document that reason. Anybody
> care to enlighten me, or give me a link?

Until quite recently, pip (if just told to "pip install Django" without
version specification) would install the latest release found on PyPI,
regardless of whether it was a pre-release or final release. This was a
very good reason not to put pre-releases on PyPI.

Now that pip defaults to not installing pre-releases, there might be an
argument for changing that policy. There may still be a concern about
people still using older versions of pip in their deployment systems (or
easy_install, which I don't think avoids pre-releases?) suddenly
beginning to accidentally install pre-releases.

Carl

[Tim Graham]

Here is the ticket for putting pre-releases on PyPI.

https://code.djangoproject.com/ticket/21108

We tried it for 1.7 alpha but it didn't work.

[Andre Terra]

On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert <ry...@ryanhiebert.com> wrote:

> I see two benefits. One is that users who are interested in testing
> aren't necessarily going to think to go to github; they're likely to
> look for the most recent release and use that (on the other hand, if
> they see a beta 4 and an RC 1, they might not necessarily realize the
> beta 4 is most recent either, so I take your point). The second
> benefit is that the instructions "pull the latest from github" can
> *sound* like a lot of work if the user is not a contributor and isn't
> experienced with git, and that might deter them from testing.

That makes sense to me. It’s basically the same reasons that a release on PyPI would be helpful: it sounds easier to a newcomer. If there’s consensus on that point (I still think git is pretty easy, but I’ve been using it quite a while), then I’m comfortable with the compromise of the RC nomenclature.

I respectfully disagree. Honestly, newcomers benefit more from learning 'git clone foo' than from downloading tarballs from PyPI. For one thing, they are probably going to need to learn it sooner or later and use version control in their own projects, together with pip and virtualenv, lest they want to go into a rabbit hole of frustrating import errors. *This* is what will make a newcomer give up on Django/Python.

The learning curve for pulling something off a git repo is inexistent. We're not asking them to git bisect, after all. It should be the standard, IMHO.

Cheers,

AT

[Ryan Hiebert]

I agree that learning to deal with git is probably one of the best things we can encourage a new user to do. To that extent, I agree with your sentiment, and if we can encourage more usage of git, I’m all for it. We are the entry point to development for many people, and if we can use our position of authority to encourage newcomers to do things right, that’s a great idea.

However, I perceived that the debate was more about the bastardization of the “release candidate” version name for something that’s not possible to release, and I’m OK with it, if it’s really going to be helpful. I, for instance, would prefer to be testing some of my projects off of a pre-release version on PyPI, at least partially because I know that pip freeze will have a version string that works (and isn’t -e with a huge git commit hash).

We can’t go back and make another beta, because the versioning won’t be properly ordered, and that’s a Bad Thing. That leaves us with either not releasing, or releasing an RC with known bugs. The RC turning into a release possibility isn’t such a hard requirement for me, it’s just another, more polished, beta version, that’s closer to release. I certainly don’t want to stop being able to versioning things just because we’re getting lots of help finding bugs.

Ryan

[Andre Terra]

On Fri, Jul 25, 2014 at 5:12 PM, Ryan Hiebert <ry...@ryanhiebert.com> wrote:

I agree that learning to deal with git is probably one of the best things we can encourage a new user to do. To that extent, I agree with your sentiment, and if we can encourage more usage of git, I’m all for it. We are the entry point to development for many people, and if we can use our position of authority to encourage newcomers to do things right, that’s a great idea.

However, I perceived that the debate was more about the bastardization of the “release candidate” version name for something that’s not possible to release, and I’m OK with it, if it’s really going to be helpful. I, for instance, would prefer to be testing some of my projects off of a pre-release version on PyPI, at least partially because I know that pip freeze will have a version string that works (and isn’t -e with a huge git commit hash).

We can’t go back and make another beta, because the versioning won’t be properly ordered, and that’s a Bad Thing. That leaves us with either not releasing, or releasing an RC with known bugs. The RC turning into a release possibility isn’t such a hard requirement for me, it’s just another, more polished, beta version, that’s closer to release. I certainly don’t want to stop being able to versioning things just because we’re getting lots of help finding bugs.

Ryan

Touché. I guess my complaint was mostly directed to Ian's original post -- claiming that to tell a user to git clone is confusing -- than at your concerns about the beta/RC debacle. FWIW, I also believe an RC2 is the correct path to pursue, because practicality beats purity. It's pretty clearly the lesser of two evils.

Best,

AT

[Schmitt, Christian]

Currently I don't think there is a need for a second RC yet. 

As already said you could easily install via Git (maybe we should add that to the docs)

Like:

"If you want to test the latest development version of Django just use pip and git to install it:

 pip install git+https://github.com/django/django.git@stable/1.7.x" 

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKBiv3xju0ecpu%3D6GrjZeyRkte09-gY-PexXGWCPwcWzkoAiig%40mail.gmail.com.