On Mon, Aug 24, 2015 at 9:32 PM, Ryan Hiebert wrote:
>
> > On Aug 24, 2015, at 5:37 PM, Carl Meyer wrote:
> >
> >> Any ideas on alternative ways to tackle this? I'm officially stuck.
> >
> > I'm afraid I don't have any solution to offer, other than
> On Aug 24, 2015, at 5:37 PM, Carl Meyer wrote:
>
>> Any ideas on alternative ways to tackle this? I'm officially stuck.
>
> I'm afraid I don't have any solution to offer, other than embracing the
> "abstract vs concrete" dependencies distinction, and accepting the fact
>
Hi Christian,
On 08/24/2015 03:52 PM, Christian Hammond wrote:
> pip's removed support for dependency_links, requiring that all package
> dependencies be made available on PyPI. This means there's no way we can
> host a build of this ourselves, have a project depend on it, and build
> the project
On Wed, Aug 19, 2015 at 4:43 PM, Markus Holtermann wrote:
> Hey Christian,
>
> On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote:
>
>> Regarding the version number, from what I've read, there's still a
>> reported
>> compatibility issue if we use the
Hey Christian,
On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote:
Regarding the version number, from what I've read, there's still a reported
compatibility issue if we use the +localidentifer part of a version number
with older versions of setuptools. I need to do some testing
Hey everyone,
Thanks for the quick feedback on this :)
Regarding the version number, from what I've read, there's still a reported
compatibility issue if we use the +localidentifer part of a version number
with older versions of setuptools. I need to do some testing on this. If I
don't hit any
Hi Christian,
On 08/18/2015 08:01 PM, Christian Hammond wrote:
[snip]
> Also as a status update, we've started a fork and applied for the
> pre-notification list. I've backported all current security fixes to a
> branch, ensured the test suite passes with flying colors, and have added
> a README
On 08/19/2015 09:38 AM, Donald Stufft wrote:
> Do we have any evidence that users will notice a fourth digit and
> will make the mental association that they are not official releases?
> I wouldn’t if I hadn’t read this thread. I mean I don’t actually care
> if they use 1.6.11.x or 1.6.12+, I just
On August 19, 2015 at 11:31:46 AM, Carl Meyer (c...@oddbird.net) wrote:
> On 08/19/2015 09:28 AM, Donald Stufft wrote:
> > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> >> In my ideal world, the version number would help convey unofficial-ness
> >> a bit more
Very happy with 1.6.11.x
On 19 August 2015 at 16:31, Carl Meyer wrote:
> On 08/19/2015 09:28 AM, Donald Stufft wrote:
> > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> >> In my ideal world, the version number would help convey unofficial-ness
> >> a
Hi Christian,
On 08/18/2015 08:01 PM, Christian Hammond wrote:
> I know it's been a while since we discussed this, but today's security
> release is the first one that's really affecting our product and we've
> finally got things in shape to be able to start distributing unofficial
> Django
On 08/19/2015 09:28 AM, Donald Stufft wrote:
> On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
>> In my ideal world, the version number would help convey unofficial-ness
>> a bit more strongly, but after re-reading PEP 440 I don't think it
>> leaves us with any good
On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> Hi Christian,
>
> On 08/18/2015 08:01 PM, Christian Hammond wrote:
> > I know it's been a while since we discussed this, but today's security
> > release is the first one that's really affecting our product and we've
> >
Hi Carl,
I know it's been a while since we discussed this, but today's security
release is the first one that's really affecting our product and we've
finally got things in shape to be able to start distributing unofficial
Django security releases (we've also just been swamped since our
Carl, your proposal sounds good to me. I would be happy to contribute to a
DEP, if formalization of the process is necessary.
Christian, let's coordinate to set up a public/private repo pair with the
appropriate warnings and have one of us apply for the pre-release
notifications (if you haven't
Sounds broadly good to me. I'd be happy for it to be pushed to pypi under
django-legacy or similar name.
Marc
On 27 Mar 2015 16:36, "Tim Graham" wrote:
> Sounds good to me.
>
> On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote:
>>
>> Hi Christian,
>>
>> On
Sounds good to me.
On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote:
>
> Hi Christian,
>
> On 03/26/2015 05:11 PM, Christian Hammond wrote:
> > I know you guys are still sorting out how you want to run this, but I
> > wanted to let you know that, given our current dependence on
Hi Christian,
On 03/26/2015 05:11 PM, Christian Hammond wrote:
> I know you guys are still sorting out how you want to run this, but I
> wanted to let you know that, given our current dependence on Python 2.6,
> I'm willing to do what's needed to maintain security backports for
> either an
Hi John and Christian,
On 03/27/2015 09:46 AM, John Paulett wrote:
> James, thanks for putting this together.
>
> Christian, I am in a similar position, supporting 2.6 for the next 6-12
> months. I had planned to keep a personal fork of Django 1.6,
> backporting security patches as needed, but
James, thanks for putting this together.
Christian, I am in a similar position, supporting 2.6 for the next 6-12
months. I had planned to keep a personal fork of Django 1.6, backporting
security patches as needed, but I would be happy to contribute to a common
effort in this regard.
As
Instructions for requesting to be added to the security prenotification
list are here:
https://docs.djangoproject.com/en/dev/internals/security/#requesting-notifications
On Thursday, March 26, 2015 at 7:11:12 PM UTC-4, Christian Hammond wrote:
>
> Hi Carl, James,
>
> Sorry for the late reply on
Hi Carl, James,
Sorry for the late reply on this. I've been unavailable the past week.
I know you guys are still sorting out how you want to run this, but I
wanted to let you know that, given our current dependence on Python 2.6,
I'm willing to do what's needed to maintain security backports
Hi James,
When I read your proposal I thought -- "this makes sense, but if maintainers
are making this commitment, they should be part of the Django team".
Only after reading Carl's comment did I realize that they shouldn't be part
of
the team in order to keep the "unofficial" aspect.
This
Hi James,
Thanks for taking the time to write this up carefully, research the
history, etc. I think some form of extended community-based support
could work, but I have some concerns about your specific proposal;
mostly, that it places too much of the responsibility with the core team.
My
Hi All,
I am free of 2.6 websites myself (and nearly free of 2.x completely), but I
think this makes sense and I'm certainly in favor of community-maintained
longer support periods of django versions, assuming people want to do it :)
Two thoughts:
- This doesn't _need_ to happen through
There's been some recent discussion in a django-users thread[1] about
the impending end-of-life of Django 1.6, which in turn will mean
end-of-life for Django supported on Python 2.6. In addition, the
end-of-life of the current LTS release, Django 1.4, will mean
end-of-life for Django supported on
26 matches
Mail list logo