[Stackless] stackless_version.h

Christian Tismer tismer at stackless.com
Fri Mar 7 23:50:47 CET 2014


And why can we not just append it, see

Python 3.3.3 (default, Dec 11 2013, 11:44:19)

Some string could get inside at the end of the brackets.

Agreed that for Stackless 2.8, it is not necessary, because there we
have the versioning totally under control.

But what about the other versions which are still Python?

- C.


On 07/03/14 21:41, Richard Tew wrote:
> My assumption is that most users will relate to the PEP 0404
> numbering, and won't have a use for the Stackless versioning.
> 
> Rather than:
> 
> Stackless x.y SLP z.q
> 
> I propose we have:
> 
> Stackless x.y
> 
> And then have z.q queryable through 'stackless.getversion()' or
> something similar.
> 
> 
> On 3/8/14, Christian Tismer <tismer at stackless.com> wrote:
>> The Stackless version was never maintained very well.
>>
>> "3.1b3" never changed after  2004-06-03  (!)
>> and so the version string was "3.1b3 040603".
>>
>> The version number was kept until today (although I wanted it to be changed,
>> when major changes were done, but did not do it myself).
>>
>> From time to time I updated the date of the stackless version, like
>> these findings in an email history search:
>> ...
>> ! #define STACKLESS_VERSION "3.1b3 040719"
>> ...
>> ! #define STACKLESS_VERSION "3.1b3 041130"
>> ...
>>  /* keep this entry up-to-date */
>> -#define STACKLESS_VERSION "3.1b3 050929"
>> +#define STACKLESS_VERSION "3.1b3 060504"
>>
>> Andrew Dahlke did in fact what the comment says:
>>  /* keep this entry up-to-date */
>> -#define STACKLESS_VERSION "3.1b3 060504"
>> +#define STACKLESS_VERSION "3.1b3 060516"...
>>
>> For the records: 2006-05-15 was the first time that the PyQT problem was
>> mentioned ;-)
>>
>> So the 3.1b3 was never ever changed, even not on the 2006 Stackless sprint.
>>
>>
>> On ditching the number:
>> ---------------------
>>
>> The number was meant to show a version of stackless design, which worked
>> until that 3.1b3 version.
>> The date was there to see when a version was created.
>>
>> I think it is bad do just ditch it, and it is bad to keep it as it is.
>>
>> When we submit stackless 2.8, the problem becomes worse, because
>> then the version number is the 0404 replacement for Python, and then
>> we have no version number for Stackless itself, at all.
>>
>> What to do?
>>
>> After all that many refinements, improvements and changes, a version
>> bump for
>> the stackless design is needed, and after all the new 3.x versions of
>> Python,
>> I think it is better to go on more drastically.
>>
>> What about the following example:
>>
>>     "Stackless 2.8 SLP 4.0"  for the 404 case, maybe with a SLP date
>> string as well
>>     "Stackless 2.8 SLP 4.0 140207"
>>
>> and in the 2.7/3.x case until we completely migrate to Stackless:
>>
>>     "Python 3.3 SLP 4.0 140207"
>>     "Python 2.7.6 SLP 4.0 140207"
>>
>> or should we toss the "design date" in favor of finer SLP versioning?
>>
>> I think we should not go completely without it, but keep it apart from
>> python
>> version numbers, and also do an announcement.
>>
>> cheers - Chris
>>
>>
>> On 04.03.14 20:26, Richard Tew wrote:
>>> You mean like:
>>>
>>> Python 3.2.5 Stackless 3.2.
>>>
>>> It looks confusing.  Better just to ditch the number I think.
>>>
>>> On 3/5/14, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:
>>>> why not just go with 3.2?  Does anyone use this number at all anyway?
>>>>
>>>>> -----Original Message-----
>>>>> From: stackless-bounces at stackless.com [mailto:stackless-
>>>>> bounces at stackless.com] On Behalf Of Richard Tew
>>>>> Sent: 3. mars 2014 02:20
>>>>> To: stackless at stackless.com
>>>>> Subject: [Stackless] stackless_version.h
>>>>>
>>>>> 3.1b3 060516 is kind of a magic number, maybe we could do away with it?
>>>>> I
>>>>> was going to bump it to 3.2, but decided it would be a little confusing.
>>>>>
>>>>> Objections?
>>>>>
>>>>> Python 2.7.6r2 Stackless 3.1b3 060516 (default, Mar  3 2014, 15:11:44)
>>>>> [MSC
>>>>> v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or
>>>>> "license"
>>>>> for more information.
>>>>>
>>>>> Cheers,
>>>>> Richard.
>>>>>
>>>>> _______________________________________________
>>>>> Stackless mailing list
>>>>> Stackless at stackless.com
>>>>> http://www.stackless.com/mailman/listinfo/stackless
>>>> _______________________________________________
>>>> Stackless mailing list
>>>> Stackless at stackless.com
>>>> http://www.stackless.com/mailman/listinfo/stackless
>>>>
>>> _______________________________________________
>>> Stackless mailing list
>>> Stackless at stackless.com
>>> http://www.stackless.com/mailman/listinfo/stackless
>>
>>
>> --
>> Christian Tismer             :^)   <mailto:tismer at stackless.com>
>> Software Consulting          :     Have a break! Take a ride on Python's
>> Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
>> 14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
>> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>> PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>>       whom do you want to sponsor today?   http://www.stackless.com/
>>
>>
>> _______________________________________________
>> Stackless mailing list
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
> 


-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



More information about the Stackless mailing list