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

[Fernando Perez]

Good summary, Damian :)

On Sun, Jul 5, 2015 at 8:39 PM, Damián Avila <damianavila at gmail.com> wrote:

> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150706/bb8e060e/attachment.html>