A new version (v1.0.1-auto.0) has been released.

  • GNU/Linux Admin

    Prior to v1.0.0 (and I suppose up until yesterday, really), "stable" was "check out v1.x.x branch". This changed as Misty will now release automated builds weekly to that same branch, so now "stable" is "check out the v1.0.0 tag".

    I've modified the documentation to reflect this, and the command is essentially unchanged:

    git clone -b v1.0.0 https://github.com/NodeBB/NodeBB.git nodebb

  • Swedes

    @julian said:

    git clone -b v1.0.0 https://github.com/NodeBB/NodeBB.git nodebb

    How does that work, i have looked. There is no branch called v1.0.0

    -b is only for branch right?

    I get this

    commit fb4f1e1315bed7b425756ad25a396c42b2ba3891
    Author: Julian Lam [email protected]
    Date: Mon Feb 29 11:37:19 2016 -0500

    But what about the important bug patches?like

    commit 8f8fcc84168d424c7bdbf16ad4afae2cca36991c
    Author: BarıÅ~_ Soner UÅ~_aklı [email protected]
    Date: Sat Mar 5 11:46:11 2016 +0200

    backport upgradescript fix for global moderators
    
  • Plugin & Theme Dev

    @Jenkler

    --branch <name>, -b <name>
        Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository’s HEAD, point to <name> branch instead. In a non-bare repository, this is the branch that will be checked out.  --branch can also take tags and detaches the HEAD at that commit in the resulting repository.
    

    Notice the last sentence 😉

  • Swedes

    But if I checkout a tag I dont get important bug patches.

  • GNU/Linux Admin

    @Jenkler "backported" changes behaviour has also changed.

    Prior to yesterday, we'd backport changes by cherry-picking them into v1.x.x branch.

    From now on, every time a change is important enough that it would've been backported, we will manually release a new patch version (which is how it is supposed to be done).

    These are good questions -- I will distill them all into a blog post today or tomorrow.

  • GNU/Linux Admin

    Remember, before we didn't get to play with major version numbers... it was always 0.x.x. Now we have the option to bump up:

    • a major version number (if it contains breaking changes)
    • a minor version number (backwards compatible changes, deprecation notices)
    • a patch version number (for... you guessed it, patches!!)
  • Swedes

    Ok, so -b is for tags ans branches.

    1. If i first checkout "git checkout -b v1.0.0. How do i update it? git checkout -b v1.0.1 (Lets say we have a v1.0.1 tag)
    2. Is it possible to downgrade? If i have updated to v1.0.1-auto.0, can i checkout tag git checkout -b v1.0.0 and downgrade (nodebb upgrade)or is that dangerous?
  • GNU/Linux Admin

    I think unofficially, patch versions should not contain upgrade scripts, and so they should be backwards compatible. That said autogenerated builds don't distinguish between them, so it would be difficult to say.

    Best advice is to only move forwards, never backwards.

    Given some of the opinions in this topic, I'm modifying Misty's behaviour to publish to a weekly release branch instead of the traditionally stable v1.x.x

  • Swedes

    Sounds good 😉 Thanks


  • @julian @Jenkler What is the tl;dr take away from all of this?

    My PRD is still v0.9.4. Should I wait for v1.0.1 or do something now with v1.x.x?

    Thank you.

  • Swedes

    @rod I have updated my prod to v1.0.0 tag at the moment. Seems to work fine 😉

  • GNU/Linux Admin

    @rod You can stick to v0.9.4, or check out v1.0.0 tag as @Jenkler has.

    v1.0.1 should be released in the next couple days anyhow.


  • Thank you. I will wait for v1.0.1 and then re-do my DEV environment to test it.

    In my DEV currently I did a git checkout v1.x.x. Once v1.0.1 is released will I continue to use v1.x.x or will I specifically reference v1.0.1?

  • GNU/Linux Admin

    You should stick to v1.x.x branch 😄


Suggested Topics

| | |

© 2014 – 2022 NodeBB, Inc. — Made in Canada.