I don't see a reason why calling it 2.8 shouldn't be a problem if Kristjan's already received the thumbs up.
Also, I think we should always provide binaries. Most of us compiling it ourselves, is not representative of the people who download prebuilt binaries and installers who would probably not otherwise bother with Stackless. My take has always been that Stackless has always been niche, and misrepresented with people making mistaken comparisons to generator coroutines or that it "doesn't use the stack." It's only a good thing for Stackless to be more approachable, so people can try it out on a whim. On that subject, we haven't done binary only releases for the most recent versions of Stackless. The idea behind these was that they can just be extracted over a Python installation to turn it into a Stackless installation. And there is a demand for these, someone was just a few days ago moaning on stack overflow that there wasn't any way to do this. Anyway, some further thoughts. Richard. On 9/5/13, Anselm Kruis <[email protected]> wrote: > Am 03.09.2013 22:59, schrieb Richard Tew: >> The point that bothers me is that we've always done Stackless releases >> as simply something that should work as the same version of mainline >> Python, but with optional Stackless features. >> >> To some degree it seems like we should do releases of both the evolved >> Python and the normal Python both with Stackless features. > +1 for that. > > Here at science+computing we will continue to use (Stackless-) Python > 2.7 for several years. Therefore +1 for continuing Stackless 2.7. > > But there are several caveats > - We will see a few more official releases of Python 2.7. Therefore we > can't simply increase the micro version number. On the other hand, a > Python 2.8 will cause political and technical problems. I wonder, if we > could (mis-)use the releaselevel component of the Python version number? > > - How to release? Release binaries at all? Currently most of us compile > Stackless themselves. > > - Compatibility and quality: the current code base of 2.7 contains many > problematic parts. If we continue to maintain 2.7 how can we avoid > regressions? > > Regards > Anselm > > -- > Dipl. Phys. Anselm Kruis science + computing ag > Senior Solution Architect Ingolstädter Str. 22 > email [email protected] 80807 München, Germany > phone +49 89 356386 874 fax 737 www.science-computing.de > -- > Vorstandsvorsitzender/Chairman of the board of management: > Gerd-Lothar Leonhart > Vorstand/Board of Management: > Dr. Bernd Finkbeiner, Michael Heinrichs, > Dr. Arno Steitz, Dr. Ingrid Zech > Vorsitzender des Aufsichtsrats/ > Chairman of the Supervisory Board: > Philippe Miltin > Sitz/Registered Office: Tuebingen > Registergericht/Registration Court: Stuttgart > Registernummer/Commercial Register No.: HRB 382196 > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
