[IPython-dev] Proposal: soft moratorium on re-architecting for 5.0

[Damián Avila]

A lot of things to digest and reply, but I don't want to bring back very
old discussions. I just wanted to note that:

1. I felt exactly the same that Thomas raised at the top, but I also
understand the pressure on the refactoring side.
2. I think that having separate branches is the proper answer to
deal/manage this conservative/non-conservative tension.
3. There were several items/ideas exposed here, we should start other
thread to continue the discussion, in particular the docs one is important.
4. Seeing all these discussions happening on the list is really great
improvement in the way the project communicates to its users and we should
be very happy about this!


On Wed, Jul 1, 2015 at 4:36 PM Fernando Perez <fperez.net at gmail.com> wrote:

> On Wed, Jul 1, 2015 at 1:29 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>> Thomas has been informally leading the charge, so I'd be happy to follow
>> him formally on 4.0. We are in
>>
>
> Great, thanks Thomas! You're in :)
>
> I would suggest you post, on a separate thread, a summary of the release
> plan/schedule when viable.
>
>
>> good shape to have the majority of the smaller packages shipped by the
>> end of SciPy (at least 2-3 before then). The bit that gets a little tricky
>> is that we need to release IPython last (so that `ipython[all]` still
>> works, but other projects depend on it, either directly (parallel, kernel)
>> or artificially (notebook, qtconsole). I think we can still release those
>> downstream projects before IPython, though. Until IPython is released, they
>> won't be pip-installable without having done `pip install -e git:ipython`
>> first, but it lets us progress without having to do one big day of
>> releasing a half dozen packages.
>>
>
> Makes sense.
>
>
>>
>> Re: release managers, I think it's also important to note that we will
>> hopefully only need the more formal freeze/release process for the more
>> active projects (likely ipython/ipython, notebook, widgets, possibly
>> nbconvert on occasion). For the most part, the other projects should be
>> able to operate at a much more informal, frequent bugfix release pattern,
>> where major revisions are less common, and active work causes tension with
>> release.
>>
>
> Yes, I think this is very reasonable.
>
> I just want us to be more explicit and communicate better our overall
> release strategy.  Even if it's just saying this part out loud, so that
> people know what to expect...
>
> Cheers,
>
> f
>
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>  _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-- 
Damián Avila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150706/394c89b6/attachment.html>