Release 2.4

[techtonik]

Because it is hard to backport stable changes (that people need to use in their workflow right away) from 2.3 to master, I propose to cut 2.4. It will solve the broken merge problem with linefeeds and new signal/slot mechanism.

[ccordoba12]

I think this is not doable, not at this moment. It could have been possible 8 months ago (after merging the new signals and slots PR), but not now. There is a lot of work on master, some of which is pending on future PRs, so it's not ready for a new release.

Besides, you haven't mentioned exactly which are those stable changes that we should backport. Right now I'm working on a new bugfix release (2.3.5) because of several startup problems, and incompatibilities with some of our 3rd party libraries (like Jedi and Sphinx). So please tell me what those changes are to see what we can do about them.

It will solve the broken merge problem with linefeeds

But so far you're the only who has problems with linefeeds :-)

[techtonik]

I need my find and replace module in 2.3. Also, I will be working on stable branch and committing it there. As I said, master didn't work for me, and I don't have time to deal with it.

[techtonik]

It all started with this one #2400

[ccordoba12]

Why don't you submit a PR with your find and replace module against our 2.3 branch? That way I could judge its importance and see if we can merge it for 2.3.5. I could also deal with merging it with master.

I advise you not to work on 2.3 (at least if you're adding new features) because that's essentially a maintenance branch. Instead, please help us to solve the problems you have with master.

[Nodd]

I work with the master branch on a daily basis without major problems (and minor problems are very rare).
I totally understand why a bugfix release is needed, but not why we should do a half stable release.

[techtonik]

@ccordoba12 #2400 is a already a PR for 2.3.

I advise you not to work on 2.3 (at least if you're adding new features) because that's essentially a maintenance branch.

I don't know why you've chosen this strategy, but it is broken. My prediction is that there won't be any stable 3.0 release of Spyder until 2017, and I don't want to teach users master version that breaks weekly.

[techtonik]

The common strategy is release often. There is also optional add-ons early and fast. But when dealing with long term support of stable stuff, it is better to keep versions as close as possible so that bug fixes from the old ones can be ported upward without much trouble.

[techtonik]

And release major version like 2.4 that require breaking some things.

[techtonik]

If you were more experienced in distributed projects, I believe you could port compatible changes to stable branch and prevent "half stable release" vs "nightmare ports" problem.

[blink1073]

@techtonik, please remember that we are volunteers and that badgering us is not going to solve anything.

[ccordoba12]

@techtonik, my answers:

#2400 is a already a PR for 2.3

Right, I didn't notice it, sorry. Given that it's a very small change, we can have it for 2.3.5. Just follow the suggestions I gave to you in the PR :-)

I don't know why you've chosen this strategy, but it is broken.

We can't continue adding new features to the maintenance branch. I don't understand what's broken with that strategy :-)

I did add several new features after 2.3.0 because they were almost ready, and I considered that they were not going to affect stability or performance. However, I was wrong about some of them, and so I have to spend long hours debugging and fixing errors between minor releases.

My prediction is that there won't be any stable 3.0 release of Spyder until 2017

Nop, I'm planning to have a new release during the second half of this year, probably in September or October. It's true that in the past it has taken us a lot time to do new major releases, but now we have a solid dev team that's helping me to move things faster.

In any case, big projects like IPython take one year or more between major releases, so why can't we? :-) They also follow a very similar strategy to ours: keep releasing minor bugfix releases every two months or so.

I don't want to teach users master version that breaks weekly

I don't understand why you keep saying this. All core devs are using master all the time, and none of them have reported major breakages. Again, instead of complaining, please help us to solve the problems you have.

I'm also planning to release beta1 after 2.3.5 to start stabilizing things.

The common strategy is release often. There is also optional add-ons early and fast

Yes, but people also expects new features in major releases. And it'd be kind of funny releasing 2.4 and saying: "look, we have moved to a new signals and slots model" ;-) Who cares about that?

I believe you could port compatible changes to stable branch and prevent "half stable release" vs "nightmare ports" problem.

Again, what are those important things that we need to backport? You're talking only in abstract or general terms, which is really not helpful. Almost all PRs merged in master are for new features, and the rest helps to solve bugs that are not critical (like issue #1001), or bugs generated after merging the previous PRs.

For the most critical bugs (like PR #2445), I'm backporting changes by hand.

[techtonik]

@blink1073 are you sure that none of us gets paid for working on Spyder? Me, for example, would welcome such opportunity, because it is normal. But I accept your point about lowering my expectations is valid. In the end we all people and even serious professional can't do all things.

[ccordoba12]

I don't see this discussion going anywhere @techtonik. You're discussing things just in general terms and without providing concrete examples of what important things we need to backport.

Can we close this issue then?

[techtonik]

We can't continue adding new features to the maintenance branch. I don't understand what's broken with that strategy :-)

The broken stuff that features should come in a stream of small package. Not one big lump of new features that breaks everything. Take a look for Chromium, for example. It doesn't build new major version with tons of features for several years. Short iteration cycle means that features are tested early and could be fixed in time.

I did add several new features after 2.3.0 because they were almost ready, and I considered that they were not going to affect stability or performance. However, I was wrong about some of them, and so I have to spend long hours debugging and fixing errors between minor releases.

Why didn't you release 2.4.0?

It's true that in the past it has taken us a lot time to do new major releases, but now we have a solid dev team that's helping me to move things faster.

I would bet a cask on beer that it won't happen, but I can not drink beer anymore. =)

In any case, big projects like IPython take one year or more between major releases, so why can't we? :-)

Because they are not all volunteers? =) http://ipython.org/sponsors.html

I'd like to see a shorter release cycle for Spyder, so that releasing feature versions 2.4, 2.5 etc. that should not break much is easy to do as soon as new feature is ready. Rolling releases make sure that people can prepare for API breaks and gradually port their patches/extensions when they have time.

Again, instead of complaining, please help us to solve the problems you have.

Ok. Last time I tried, the master didn't work, but now it at least started, although very slow. I still want some Python 2 release, because that's the version I am working with in my binary realm. Python 3 "goodies" usually complicate the code, but things like new signals/slots could came separately, so that merging patches from 2.x is easier.

For now I needed:

• Find in Files
  • Decent Plugin Subsystem
• Fix PySide complaining about missing cursor on Ubuntu
• Reporting of UI loading time in bootstrap.py console

I'm also planning to release beta1 after 2.3.5 to start stabilizing things.

Is there a list of "things" that needs to be stabilized?

And it'd be kind of funny releasing 2.4 and saying: "look, we have moved to a new signals and slots model" ;-) Who cares about that?

If you position Spyder as a IDE that people can easily extend and customize to their liking (how it should be to provide value different from Sublime and other altenatives), then it is a very big thing. It may even need a tutorial with pictures/screens explaining how it works and how to play with that.

Again, what are those important things that we need to backport? You're talking only in abstract or general terms, which is really not helpful.

Well, I was offline for year(s), and I couldn't see those important things, because Spyder just didn't started, so the journey ended there. I will take another look, but the first impression was negative and now it will take time to change that.

[techtonik]

The new signal/slot switch is a big thing that should come with 2.4 so that people could port their extensions without bothering about Python 3 yet, so this is a thing that should be backported.

[Nodd]

Python3 is enabled since v2.3, and has nothing to do with new kind of signal/slots (which are still compatible with old style ones).
Also, where are those people and their extensions ? I would gladly use them or help upgrade them.

Decent Plugin Subsystem

It's being worked on: #2362
It's not complete but at least functional.

Fix PySide complaining about missing cursor on Ubuntu

That's not on ubuntu only, and it's an upstream bug.

Reporting of UI loading time in bootstrap.py console

You're the only one wanting that, isn't it ?

I would gladly lock this issue, but you'd just open another one...

[ccordoba12]

Closing because we're not going to release 2.4

[techtonik]

Looks like a maintenance failure. =) The reasons are Python complexity and incompatibilities between versions that are too huge to track automatically.