Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Considering semantic versioning

  1. #1
    Super Moderator Petr Schreiber's Avatar
    Join Date
    Aug 2005
    Location
    Brno - Czech Republic
    Posts
    6,839
    Blog Entries
    3
    Rep Power
    697

    Lightbulb Considering semantic versioning

    Dear Eros, dear community,

    I would like to share one concept for software development, which I find easy to follow both for developers and their users.

    It could be applied to thinBASIC, it could be applied to thinBASIC modules, it could be applied to applications you develop with thin tools.


    Semantic versioning

    Semantic versioning is often mentioned as "created by" Tom Preston-Werner. He indeed deserves the credit for keeping all the rules on one place, the system is basically a composition of common sense rules.
    It can be read in its whole here: https://semver.org/

    The approach gained significance for languages with package system, but I find it highly valuable even for other types of applications.

    In a nutshell, version is considered a set of 3 numbers:
    MAJOR.MINOR.PATCH

    Changing the major should be done only in case you introduce backwards incompatible changes.

    Changing the minor should be done in case you add new feature.

    Changing the patch should be done in case the new version introduces some fixes.

    I also like the "Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version."

    This also somehow implicates it is good idea to do pure bugfix, pure feature releases, which is a concept I like.


    The benefits

    The main benefit I see is the clear communication towards user:

    - if you are using software / module in version A.0.0, it is guaranteed the use will be the same with any A.*.* version (because A guarantees backwards compatiblity). However, you know you should be alerted once version B.*.* appears and you should not migrate without proper thought

    - if you expect certain feature from software / module, specifying version on MAJOR.MINOR level is completely sufficient

    - if you see version MAJOR.MINOR.1 and MAJOR.MINOR.2, no reason to think if I should pick first or second, the MAJOR.MINOR.2 should be of more quality (less bugs) than MAJOR.MINOR.1


    How could thinBASIC gain from this?

    ThinBASIC already offers handy #minVersion statement, which restricts the execution of script by older version of interpreter.

    It would be interesting to have something similar for thinBasic modules - very useful for 3rd party development, modules not in the standard distribution.

    Such mechanism could prevent mis-use of module with wrong version of core for example.

    Being agreed on the semantic versioning approach could also mean we could introduce some further dependency checks and restrictions, which could increase stability of the tools we use and develop.


    Petr
    Last edited by Petr Schreiber; 28-07-2018 at 19:13.
    Learn 3D graphics with ThinBASIC, learn TBGL!
    Windows 7 64bit - Intel Core 2 Duo T6600 @ 2.2GHz - 4 GB RAM - NVIDIA GeForce G210M 512MB
    Windows 8 64bit - Intel Core i5-3350P @ 3.1GHz - 8 GB RAM - NVIDIA GeForce GT640 3GB

  2. #2
    thinBasic MVPs ReneMiner's Avatar
    Join Date
    Oct 2012
    Location
    Germany
    Age
    48
    Posts
    1,241
    Blog Entries
    1
    Rep Power
    136
    That's cool.

    But I fear then there will never be thinbasic 2.0...?

    Or can it be that we finally and official completely drop support of 16 Bit-OS to make it a "valid thinbasic 2.0" ??
    maybe no PC currently but always a head full of ideas

  3. #3
    Super Moderator Petr Schreiber's Avatar
    Join Date
    Aug 2005
    Location
    Brno - Czech Republic
    Posts
    6,839
    Blog Entries
    3
    Rep Power
    697
    Hi Rene,

    I am not sure I follow here

    Why do you "fear" there will be no thinBasic 2.x?

    What do you mean by support for 16bit OS? I don't think thinBasic could run on Windows 3.1

    My proposal is generic and has benefits immediately, even for the 1.x line.


    Petr
    Learn 3D graphics with ThinBASIC, learn TBGL!
    Windows 7 64bit - Intel Core 2 Duo T6600 @ 2.2GHz - 4 GB RAM - NVIDIA GeForce G210M 512MB
    Windows 8 64bit - Intel Core i5-3350P @ 3.1GHz - 8 GB RAM - NVIDIA GeForce GT640 3GB

  4. #4
    thinBasic MVPs ReneMiner's Avatar
    Join Date
    Oct 2012
    Location
    Germany
    Age
    48
    Posts
    1,241
    Blog Entries
    1
    Rep Power
    136
    Sorry, guess I confused something with Win95/98...
    Probably it should mean no more support for
    Windows below XP, so 98 and lower. It is already required to have XP SP2 or better since 1.9.something when using TBGL, remember? Also UI already has some features that require XP SP2 I think...
    maybe no PC currently but always a head full of ideas

  5. #5
    Petr, have you made a conference with Eros about boosting TB core speed ??
    i don't want from you to disclose the secret of this boosting, but if you can post a short cryptic gestures we may feel better without disclosing the secret like the full moon..
    if this speed boosting happened then it deserve TB v2.0

  6. #6
    thinBasic author ErosOlmi's Avatar
    Join Date
    Sep 2004
    Location
    Milan - Italy
    Age
    51
    Posts
    8,343
    Blog Entries
    2
    Rep Power
    10
    Hi Petr,

    I can agree with the method you suggested but not sure it can improve something or clear something.

    I mean ...
    1. very rarely I've broken backward compatibility.
    2. Very often I release new features and fixes on the same new release but clearly stated in What's new history what is what.


    Anyway, I will better read the reference you mentioned, maybe I missed something.

    Regarding module development ... again the main interface is there since the very beginning and instead of break backward compatibility I develop new variants of the same SDK function. Like in COM development rules: once you have released an interface that interface cannot be changed and you have to release a new version.

    Yes, I agree that I've done a great mistake releasing for so long time 1.10.xxx beta phases.
    I will try to close all open items and document them and then release as stable.

    Ciao
    Eros
    www.thinbasic.com | www.thinbasic.com/community/ | psch.thinbasic.com
    Win10Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

  7. #7
    thinBasic author ErosOlmi's Avatar
    Join Date
    Sep 2004
    Location
    Milan - Italy
    Age
    51
    Posts
    8,343
    Blog Entries
    2
    Rep Power
    10
    Quote Originally Posted by primo View Post
    Petr, have you made a conference with Eros about boosting TB core speed ??
    i don't want from you to disclose the secret of this boosting, but if you can post a short cryptic gestures we may feel better without disclosing the secret like the full moon..
    if this speed boosting happened then it deserve TB v2.0
    Ciao Primo,

    thinBasic speed is something I do not think I will be able to improve as a "general" improvement.
    Maybe I will improve some specific function or some specific aspect but the main speed is influenced "negatively" by the interpretative nature of the language.
    To boost it I should transform thinBasic into an intermediate pCode generator and then have an executor able to execute intermediate pCode.
    But that is not in my head at the moment.

    If you need SPEED for example for you great fractal and math script where thousands or millions of loops are the basis ... I'm sorry and reluctant to say that thinBasic ha limits on that.

    What I can say is that I'm always on the "more speed the better it is" line when I develop something.
    So I will always continue to improve execution speed but never expect "jumps" on that aspect.

    Ciao
    Eros
    www.thinbasic.com | www.thinbasic.com/community/ | psch.thinbasic.com
    Win10Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

  8. #8
    thinBasic author ErosOlmi's Avatar
    Join Date
    Sep 2004
    Location
    Milan - Italy
    Age
    51
    Posts
    8,343
    Blog Entries
    2
    Rep Power
    10
    Quote Originally Posted by ReneMiner View Post
    That's cool.

    But I fear then there will never be thinbasic 2.0...?

    Or can it be that we finally and official completely drop support of 16 Bit-OS to make it a "valid thinbasic 2.0" ??
    Ciao Renč

    16 bit are not supported at all.
    Even Windows XP ... Core engine is compatible but some of the modules I think not.

    Anyway, version 2.x of thinBasic ... is something will completely change thinBasic Core engine.
    My idea of version 2.x is related on multi threading and will for sure break backward compatibility because for every internal and external function calling a new parameter (current thread) will be needed so all SDK function will be rewritten.

    For modules development it will not change too much but they will need to be rewritten to pass one DWORD parameter that will be passed to all SDK function calling.

    Ciao
    Eros
    Last edited by ErosOlmi; 30-07-2018 at 14:53.
    www.thinbasic.com | www.thinbasic.com/community/ | psch.thinbasic.com
    Win10Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

  9. #9
    Super Moderator Petr Schreiber's Avatar
    Join Date
    Aug 2005
    Location
    Brno - Czech Republic
    Posts
    6,839
    Blog Entries
    3
    Rep Power
    697
    Hi Eros,

    my apologies for the confusion - I tried to sum it up in the last paragraph, but maybe it made no sense.

    You might remember I had a pretty confusing versioning policy for TBGL, where I kept my independent versioning, then I switched to sync with ThinBASIC versioning, but - sense it makes little, as it does not say much about the api compatibility of the module itself.

    I did some research and found semver, which I find good to follow and basically what you do all the time with thinBasic.

    The point I wanted to make with the post is that:
    - it would be nice to have some document, which could be shown to new module / unit developers with the comment "this is the set of rules we follow"
    - it would be nice to have mechanism to verify, whether module is compatible with core (possible by following this idea)

    The second one would need some tuning in core, not sure how exactly yet. I wanted to open discussion on that topic.

    You might remember me thinking out loud about package/dependency management for thinBASIC. Having such a mechanism could make it easier.

    My apologies if you understood it as critique/complaint.


    Petr
    Last edited by Petr Schreiber; 30-07-2018 at 19:32.
    Learn 3D graphics with ThinBASIC, learn TBGL!
    Windows 7 64bit - Intel Core 2 Duo T6600 @ 2.2GHz - 4 GB RAM - NVIDIA GeForce G210M 512MB
    Windows 8 64bit - Intel Core i5-3350P @ 3.1GHz - 8 GB RAM - NVIDIA GeForce GT640 3GB

  10. #10
    Hi Petr,

    I like the scheme. We can adopt it for o2, starting soon with the self-compiling betas.
    o2_version will also return an ISO timestamp, following the version numbers:

    0.1.0 2018-07-31T07:29:00

Page 1 of 2 12 LastLast

Similar Threads

  1. TopDown versioning
    By Petr Schreiber in forum Game sources
    Replies: 5
    Last Post: 04-03-2007, 02:58

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •