[Question] Wild guess ETA of support 3.x release GA

[pagratios]

trafficstars

Hello team,

Do you have any wild guess on when the support of 3.x will be released GA? It seems that beta with alpha has 1 year different. That means that GA might take 1 more year?

Thank you in advance :)

[slozier]

We had planned on moving on to 3.6-alpha after the 3.4-beta release, but I hadn't considered that people might be waiting for a "final" release before using 3.x... In my opinion the beta release is probably GA-quality already, but if you feel a final v3.4.0 release is desirable we can certainly reconsider our plans and look into this.

[BCSharp]

I have realized that for some people/projects, the official status of a "final" release is important. I know some parties that would not touch "alpha" because of its status. The "beta" may attract more users but some project may be reluctant to migrate from ipy2 "final" to ipy3 "beta" because of the perceived maturity downgrade. But it is more than just a matter of perception. An official "final"/stable release means that (1) no new potentially unstable development takes place on top of it, and (2) bugfixes are being applied.

Given the current limited resources I believe that the IronPython project can only reasonably support at most two branches. For quite some time those branches were ironpython2/master (stable) and ironpython3/master (leading-edge). Making a "final" release of IronPython 3 will effectively mean that IronPython 2 becomes "out-of-support". This means no more of ipy2 releases, or bugfixes, even when found and fixed in ipy3. Sure, people can still submit pull request that may or may not be merged, but effectively ipy2 becomes end-of-life.

So here are some ideas: instead of ipy2, a separate support branch of 3.4 would be maintained, that only contains essential bugfixes from the leading-edge master branch of ipy3. Porting some fixes from master to this 3.4 branch should theoretically be easier than backports to ipy2 because the code is more similar. So we would have again only two branches, ironpython3/master and ironpython3/3.4.

Now the question is how to get there. I think it is fair to give "beta" some time to get feedback on quality and bugs from folks that would not dab in "alpha", before making a "final" release. Since slozier/stdlib-3.6 is now practically the leading edge, the current master will receive only bugfixes or other improvements that do not jeopardize stability (like fixes in build, installation, usage, packaging, small and localized upgrades, etc.). I am OK with that, there is plenty of stuff of this caliber that can be done. Once stdlib-3.4 is ready for merge into master, we branch off 3.4 from the last commit before merge. This becomes the stable branch that will lead to the "final" and post-final releases of 3.4, fully replacing ipy2.

[pagratios]

You are right that a final version of a project version makes it more desirable for others people/project to use it. Even if the beta is final-quality the final word is still better 😄

Python 2.7.x has been marked as EOL from Jan 2020, with this in mind I think you can stop supporting the ipy2 and move forward to have a final ipy3 version.

Do you think that you can move to ipy3/3.4-final in a couple of months?

[slozier]

Yes, a couple of months is a reasonable estimate.