https://wiki.luxcorerender.org/api.php?action=feedcontributions&feedformat=atom&user=HowetuftLuxCoreRender Wiki - User contributions [en]2026-10-19T18:53:28ZUser contributionsMediaWiki 1.43.9https://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2915Branching and Version Control2026-10-05T03:43:09Z<p>Howetuft: /* Strategy */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
<br />
<br />
= General Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b><br />
<br />
<br />
This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b><br />
<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
= Details =<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.<br />
<br />
= Appendices =<br />
<br />
== Appendix A: A few considerations that oriented our choice ==<br />
<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2914Branching and Version Control2026-10-05T03:42:35Z<p>Howetuft: </p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b><br />
<br />
<br />
This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b><br />
<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
= Details =<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.<br />
<br />
= Appendices =<br />
<br />
== Appendix A: A few considerations that oriented our choice ==<br />
<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2913Branching and Version Control2026-10-05T03:39:48Z<p>Howetuft: /* Strategy */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b><br />
<br />
<br />
This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b><br />
<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.<br />
<br />
= Appendix: A few considerations that oriented our choice =<br />
<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2912Branching and Version Control2026-10-05T03:38:20Z<p>Howetuft: /* Strategy */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b><br />
<br />
This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b><br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.<br />
<br />
= Appendix: A few considerations that oriented our choice =<br />
<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2911Branching and Version Control2026-10-05T03:37:10Z<p>Howetuft: </p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.<br />
<br />
= Appendix: A few considerations that oriented our choice =<br />
<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Release_Notes_v2.11&diff=2910LuxCoreRender Release Notes v2.112026-09-20T03:36:31Z<p>Howetuft: /* Bugfix release v2.11.1 */</p>
<hr />
<div>= Bugfix release v2.11.2 =<br />
'''LuxCore'''<br />
* Fix an error that indefinitely blocks viewport-GPU rendering<br />
* Improve dynamic library loading on Linux, fixes tbb-related crashes on Linux with Blender 4.5 LTS<br />
<br />
= Bugfix release v2.11.1 =<br />
'''LuxCore'''<br />
<br />
Note: LuxCore was directly released as 2.11.1 due to an immediate bug during release, which was not revertible due to PyPIs strict versioning.<br />
<br />
'''BlendLuxCore'''<br />
* Point to LuxCore v2.11.2<br />
* Fix initial assignment of the world cache. Reduces unnecessary viewport restart.<br />
* Fix an issue with LuxcoreOnlineLibrary preview images in Blender 5.0+<br />
<br />
= BlendLuxCore =<br />
'''Coding/Backend'''<br />
* Include "OptiX" in addon settings label to avoid user questions about compatibility<br />
* Remove leftover code from the Addons system that is no longer used with the Extensions system.<br />
* Use LuxCore internal OIDN (rather than embedding and calling an external OIDN executable)<br />
<br />
'''Bugfix'''<br />
* Added a workaround for a Blender bug that throws an error when Blender is closed https://projects.blender.org/blender/blender/issues/140488<br />
* Limit float values in viewport render to 16-bit in order to avoid overexposed areas being displayed as black.<br />
* Fix rounding of convergence percentage, reaching 100% to early for complex scenes<br />
* Fix Blender crash when clicking Copy Material<br />
<br />
'''Features (of interest for users)'''<br />
* Update compatibility for Blender 5.0<br />
* Fresnel texture: "custom n,k" now accepts values > 1<br />
* Remove default filtering of Intel GPU devices<br />
* Add a checkbox to the material output node for enabling an override: When using shadow color, this allows light rays in addition to the shadow rays. (default off == no light rays, only shadow rays)<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space (c.f. section LuxCore)<br />
* New shape node "MergeOnDistance" (like Blender Merge by Distance)<br />
* Subdiv: (simple) crease management<br />
<br />
<br />
= BlendLuxHelper =<br />
* Adding BlendLuxHelper: A new helper, in the form of a Blender extension, which allows to configure the wheel that is imported by BlendLuxCore.<br />
* <del>Change installation mechanism to use bpy.utils.extension_path_user()</del> (Reworked within the scope of BlendLuxHelper)<br />
* <del>Added a Linux development shell script (optional utility for developers)</del> (replaced by BlendLuxHelper)<br />
<br />
= LuxCore =<br />
<br />
'''Coding/Backend'''<br />
* Subdivision: multithreaded version, in order to improve speed<br />
* Reduction of Boost footprint, replaced with standard equivalents available in C++20.<br />
* For the need of previous point: replacement of apple-clang by clang 20 on MacOS platforms<br />
* New target 'wheel-test' that builds a testing wheel in local build (<code>make wheel-test</code>)<br />
* Requirement checking in <code>make deps</code><br />
* luxrays: rename GetConfigDir as GetCacheDir and use XDG_CACHE_HOME according to specifications (@illwieckz)<br />
* Adapt CI pipelines to MacOS-15 runners (after deprecation of MacOS-13 runners on Github)<br />
* Remove direct access to Blender internal objects. Use Blender API instead, more stable.<br />
* Add support for Python 3.14 (and remove support for 3.9)<br />
<br />
'''Bugfix'''<br />
* Fix a bug leading to unstable brightness between renderings when using saved crashes (Credit to FELIX Render developers)<br />
* Fix volume evaluation in BiDir engine https://github.com/LuxCoreRender/LuxCore/issues/647<br />
* Fix various bugs when using orthographic camera with light tracing https://github.com/LuxCoreRender/LuxCore/issues/667<br />
* Fix various memory-related issues (leaks, potential access violations...). Modernize memory handling (to be continued)<br />
* Avoid crash if no OpenCL and/or Nvidia API is found<br />
* Fix several race conditions<br />
* Fixed an error where paused renderings can't be stopped anymore<br />
* 3D-mapping: Fix inconsistent behavior between local and random-local mapping https://github.com/LuxCoreRender/BlendLuxCore/issues/656<br />
* Add a clamping in SchlickBSDF to avoid (very small) floating point issues<br />
<br />
'''Features (of interest for users)'''<br />
* Subdivision: add an "adaptive" setting to select between adaptive refinement and uniform refinement<br />
* Make `pyluxcoretools` available again (in the wheels)<br />
* Apply the behavior of the BiDir engine w.r.t. shadow color mechanism to Path+Light tracing. <b>Breaking change for scenes using shadow color and light tracing (not BiDir)!</b> https://github.com/LuxCoreRender/LuxCore/issues/671<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space https://github.com/LuxCoreRender/BlendLuxCore/issues/644<br />
<br />
= LuxCoreDeps =<br />
* Dependencies updated to latest versions<br />
* Better dependency pinning (for nvrtc and conan-index)<br />
* Removed a workaround introduced in previous version (we used to build a fake wheel to get containerization)<br />
* OpenMP - MacOS: Use of homebrew OpenMP (up-to-date, compatible with clang 20) rather than Conan llvm-openmp (version 17...). As a consequence, for MacOS Intel, a version >= 13.0 is required.<br />
* Opensubdiv: tbb activation. As a consequence, for MacOS Arm, a version >= 14.2 is required.<br />
* OpenImageIO: deactivation of several image formats that seem unrelated to or unsupported by LuxCore: freetype, hdf5, ffmpeg, libheif, ptex, opencv. This removal spares both compilation time and build result size. Those formats are reactivable, in case they were missing.<br />
* OpenImageIO: To the contrary, activation of tbb option.<br />
* Embree: Upgraded to version 4.<br />
* libjpeg: Replaced with libjpeg-turbo</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Release_Notes_v2.11&diff=2909LuxCoreRender Release Notes v2.112026-09-20T03:35:50Z<p>Howetuft: /* Bugfix release v2.11.1 */</p>
<hr />
<div>= Bugfix release v2.11.2 =<br />
'''LuxCore'''<br />
* Fix an error that indefinitely blocks viewport-GPU rendering<br />
* Improve dynamic library loading on Linux, fixes tbb-related crashes on Linux with Blender 4.5 LTS<br />
<br />
= Bugfix release v2.11.1 =<br />
'''LuxCore'''<br />
Note: LuxCore was directly released as 2.11.1 due to an immediate bug during release, which was not revertible due to PyPIs strict versioning.<br />
<br />
'''BlendLuxCore'''<br />
* Point to LuxCore v2.11.2<br />
* Fix initial assignment of the world cache. Reduces unnecessary viewport restart.<br />
* Fix an issue with LuxcoreOnlineLibrary preview images in Blender 5.0+<br />
<br />
= BlendLuxCore =<br />
'''Coding/Backend'''<br />
* Include "OptiX" in addon settings label to avoid user questions about compatibility<br />
* Remove leftover code from the Addons system that is no longer used with the Extensions system.<br />
* Use LuxCore internal OIDN (rather than embedding and calling an external OIDN executable)<br />
<br />
'''Bugfix'''<br />
* Added a workaround for a Blender bug that throws an error when Blender is closed https://projects.blender.org/blender/blender/issues/140488<br />
* Limit float values in viewport render to 16-bit in order to avoid overexposed areas being displayed as black.<br />
* Fix rounding of convergence percentage, reaching 100% to early for complex scenes<br />
* Fix Blender crash when clicking Copy Material<br />
<br />
'''Features (of interest for users)'''<br />
* Update compatibility for Blender 5.0<br />
* Fresnel texture: "custom n,k" now accepts values > 1<br />
* Remove default filtering of Intel GPU devices<br />
* Add a checkbox to the material output node for enabling an override: When using shadow color, this allows light rays in addition to the shadow rays. (default off == no light rays, only shadow rays)<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space (c.f. section LuxCore)<br />
* New shape node "MergeOnDistance" (like Blender Merge by Distance)<br />
* Subdiv: (simple) crease management<br />
<br />
<br />
= BlendLuxHelper =<br />
* Adding BlendLuxHelper: A new helper, in the form of a Blender extension, which allows to configure the wheel that is imported by BlendLuxCore.<br />
* <del>Change installation mechanism to use bpy.utils.extension_path_user()</del> (Reworked within the scope of BlendLuxHelper)<br />
* <del>Added a Linux development shell script (optional utility for developers)</del> (replaced by BlendLuxHelper)<br />
<br />
= LuxCore =<br />
<br />
'''Coding/Backend'''<br />
* Subdivision: multithreaded version, in order to improve speed<br />
* Reduction of Boost footprint, replaced with standard equivalents available in C++20.<br />
* For the need of previous point: replacement of apple-clang by clang 20 on MacOS platforms<br />
* New target 'wheel-test' that builds a testing wheel in local build (<code>make wheel-test</code>)<br />
* Requirement checking in <code>make deps</code><br />
* luxrays: rename GetConfigDir as GetCacheDir and use XDG_CACHE_HOME according to specifications (@illwieckz)<br />
* Adapt CI pipelines to MacOS-15 runners (after deprecation of MacOS-13 runners on Github)<br />
* Remove direct access to Blender internal objects. Use Blender API instead, more stable.<br />
* Add support for Python 3.14 (and remove support for 3.9)<br />
<br />
'''Bugfix'''<br />
* Fix a bug leading to unstable brightness between renderings when using saved crashes (Credit to FELIX Render developers)<br />
* Fix volume evaluation in BiDir engine https://github.com/LuxCoreRender/LuxCore/issues/647<br />
* Fix various bugs when using orthographic camera with light tracing https://github.com/LuxCoreRender/LuxCore/issues/667<br />
* Fix various memory-related issues (leaks, potential access violations...). Modernize memory handling (to be continued)<br />
* Avoid crash if no OpenCL and/or Nvidia API is found<br />
* Fix several race conditions<br />
* Fixed an error where paused renderings can't be stopped anymore<br />
* 3D-mapping: Fix inconsistent behavior between local and random-local mapping https://github.com/LuxCoreRender/BlendLuxCore/issues/656<br />
* Add a clamping in SchlickBSDF to avoid (very small) floating point issues<br />
<br />
'''Features (of interest for users)'''<br />
* Subdivision: add an "adaptive" setting to select between adaptive refinement and uniform refinement<br />
* Make `pyluxcoretools` available again (in the wheels)<br />
* Apply the behavior of the BiDir engine w.r.t. shadow color mechanism to Path+Light tracing. <b>Breaking change for scenes using shadow color and light tracing (not BiDir)!</b> https://github.com/LuxCoreRender/LuxCore/issues/671<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space https://github.com/LuxCoreRender/BlendLuxCore/issues/644<br />
<br />
= LuxCoreDeps =<br />
* Dependencies updated to latest versions<br />
* Better dependency pinning (for nvrtc and conan-index)<br />
* Removed a workaround introduced in previous version (we used to build a fake wheel to get containerization)<br />
* OpenMP - MacOS: Use of homebrew OpenMP (up-to-date, compatible with clang 20) rather than Conan llvm-openmp (version 17...). As a consequence, for MacOS Intel, a version >= 13.0 is required.<br />
* Opensubdiv: tbb activation. As a consequence, for MacOS Arm, a version >= 14.2 is required.<br />
* OpenImageIO: deactivation of several image formats that seem unrelated to or unsupported by LuxCore: freetype, hdf5, ffmpeg, libheif, ptex, opencv. This removal spares both compilation time and build result size. Those formats are reactivable, in case they were missing.<br />
* OpenImageIO: To the contrary, activation of tbb option.<br />
* Embree: Upgraded to version 4.<br />
* libjpeg: Replaced with libjpeg-turbo</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Release_Notes_v2.11&diff=2908LuxCoreRender Release Notes v2.112026-09-20T03:35:35Z<p>Howetuft: /* Bugfix release v2.10.1 */</p>
<hr />
<div>= Bugfix release v2.11.2 =<br />
'''LuxCore'''<br />
* Fix an error that indefinitely blocks viewport-GPU rendering<br />
* Improve dynamic library loading on Linux, fixes tbb-related crashes on Linux with Blender 4.5 LTS<br />
<br />
= Bugfix release v2.11.1 =<br />
'''LuxCore'''<br />
Note: LuxCore was directly released as 2.10.1 due to an immediate bug during release, which was not revertible due to PyPIs strict versioning.<br />
<br />
'''BlendLuxCore'''<br />
* Point to LuxCore v2.11.2<br />
* Fix initial assignment of the world cache. Reduces unnecessary viewport restart.<br />
* Fix an issue with LuxcoreOnlineLibrary preview images in Blender 5.0+<br />
<br />
= BlendLuxCore =<br />
'''Coding/Backend'''<br />
* Include "OptiX" in addon settings label to avoid user questions about compatibility<br />
* Remove leftover code from the Addons system that is no longer used with the Extensions system.<br />
* Use LuxCore internal OIDN (rather than embedding and calling an external OIDN executable)<br />
<br />
'''Bugfix'''<br />
* Added a workaround for a Blender bug that throws an error when Blender is closed https://projects.blender.org/blender/blender/issues/140488<br />
* Limit float values in viewport render to 16-bit in order to avoid overexposed areas being displayed as black.<br />
* Fix rounding of convergence percentage, reaching 100% to early for complex scenes<br />
* Fix Blender crash when clicking Copy Material<br />
<br />
'''Features (of interest for users)'''<br />
* Update compatibility for Blender 5.0<br />
* Fresnel texture: "custom n,k" now accepts values > 1<br />
* Remove default filtering of Intel GPU devices<br />
* Add a checkbox to the material output node for enabling an override: When using shadow color, this allows light rays in addition to the shadow rays. (default off == no light rays, only shadow rays)<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space (c.f. section LuxCore)<br />
* New shape node "MergeOnDistance" (like Blender Merge by Distance)<br />
* Subdiv: (simple) crease management<br />
<br />
<br />
= BlendLuxHelper =<br />
* Adding BlendLuxHelper: A new helper, in the form of a Blender extension, which allows to configure the wheel that is imported by BlendLuxCore.<br />
* <del>Change installation mechanism to use bpy.utils.extension_path_user()</del> (Reworked within the scope of BlendLuxHelper)<br />
* <del>Added a Linux development shell script (optional utility for developers)</del> (replaced by BlendLuxHelper)<br />
<br />
= LuxCore =<br />
<br />
'''Coding/Backend'''<br />
* Subdivision: multithreaded version, in order to improve speed<br />
* Reduction of Boost footprint, replaced with standard equivalents available in C++20.<br />
* For the need of previous point: replacement of apple-clang by clang 20 on MacOS platforms<br />
* New target 'wheel-test' that builds a testing wheel in local build (<code>make wheel-test</code>)<br />
* Requirement checking in <code>make deps</code><br />
* luxrays: rename GetConfigDir as GetCacheDir and use XDG_CACHE_HOME according to specifications (@illwieckz)<br />
* Adapt CI pipelines to MacOS-15 runners (after deprecation of MacOS-13 runners on Github)<br />
* Remove direct access to Blender internal objects. Use Blender API instead, more stable.<br />
* Add support for Python 3.14 (and remove support for 3.9)<br />
<br />
'''Bugfix'''<br />
* Fix a bug leading to unstable brightness between renderings when using saved crashes (Credit to FELIX Render developers)<br />
* Fix volume evaluation in BiDir engine https://github.com/LuxCoreRender/LuxCore/issues/647<br />
* Fix various bugs when using orthographic camera with light tracing https://github.com/LuxCoreRender/LuxCore/issues/667<br />
* Fix various memory-related issues (leaks, potential access violations...). Modernize memory handling (to be continued)<br />
* Avoid crash if no OpenCL and/or Nvidia API is found<br />
* Fix several race conditions<br />
* Fixed an error where paused renderings can't be stopped anymore<br />
* 3D-mapping: Fix inconsistent behavior between local and random-local mapping https://github.com/LuxCoreRender/BlendLuxCore/issues/656<br />
* Add a clamping in SchlickBSDF to avoid (very small) floating point issues<br />
<br />
'''Features (of interest for users)'''<br />
* Subdivision: add an "adaptive" setting to select between adaptive refinement and uniform refinement<br />
* Make `pyluxcoretools` available again (in the wheels)<br />
* Apply the behavior of the BiDir engine w.r.t. shadow color mechanism to Path+Light tracing. <b>Breaking change for scenes using shadow color and light tracing (not BiDir)!</b> https://github.com/LuxCoreRender/LuxCore/issues/671<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space https://github.com/LuxCoreRender/BlendLuxCore/issues/644<br />
<br />
= LuxCoreDeps =<br />
* Dependencies updated to latest versions<br />
* Better dependency pinning (for nvrtc and conan-index)<br />
* Removed a workaround introduced in previous version (we used to build a fake wheel to get containerization)<br />
* OpenMP - MacOS: Use of homebrew OpenMP (up-to-date, compatible with clang 20) rather than Conan llvm-openmp (version 17...). As a consequence, for MacOS Intel, a version >= 13.0 is required.<br />
* Opensubdiv: tbb activation. As a consequence, for MacOS Arm, a version >= 14.2 is required.<br />
* OpenImageIO: deactivation of several image formats that seem unrelated to or unsupported by LuxCore: freetype, hdf5, ffmpeg, libheif, ptex, opencv. This removal spares both compilation time and build result size. Those formats are reactivable, in case they were missing.<br />
* OpenImageIO: To the contrary, activation of tbb option.<br />
* Embree: Upgraded to version 4.<br />
* libjpeg: Replaced with libjpeg-turbo</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=LuxCoreRender_Release_Notes_v2.11&diff=2907LuxCoreRender Release Notes v2.112026-09-20T03:35:25Z<p>Howetuft: /* Bugfix release v2.10.2 */</p>
<hr />
<div>= Bugfix release v2.11.2 =<br />
'''LuxCore'''<br />
* Fix an error that indefinitely blocks viewport-GPU rendering<br />
* Improve dynamic library loading on Linux, fixes tbb-related crashes on Linux with Blender 4.5 LTS<br />
<br />
= Bugfix release v2.10.1 =<br />
'''LuxCore'''<br />
Note: LuxCore was directly released as 2.10.1 due to an immediate bug during release, which was not revertible due to PyPIs strict versioning.<br />
<br />
'''BlendLuxCore'''<br />
* Point to LuxCore v2.11.2<br />
* Fix initial assignment of the world cache. Reduces unnecessary viewport restart.<br />
* Fix an issue with LuxcoreOnlineLibrary preview images in Blender 5.0+<br />
<br />
= BlendLuxCore =<br />
'''Coding/Backend'''<br />
* Include "OptiX" in addon settings label to avoid user questions about compatibility<br />
* Remove leftover code from the Addons system that is no longer used with the Extensions system.<br />
* Use LuxCore internal OIDN (rather than embedding and calling an external OIDN executable)<br />
<br />
'''Bugfix'''<br />
* Added a workaround for a Blender bug that throws an error when Blender is closed https://projects.blender.org/blender/blender/issues/140488<br />
* Limit float values in viewport render to 16-bit in order to avoid overexposed areas being displayed as black.<br />
* Fix rounding of convergence percentage, reaching 100% to early for complex scenes<br />
* Fix Blender crash when clicking Copy Material<br />
<br />
'''Features (of interest for users)'''<br />
* Update compatibility for Blender 5.0<br />
* Fresnel texture: "custom n,k" now accepts values > 1<br />
* Remove default filtering of Intel GPU devices<br />
* Add a checkbox to the material output node for enabling an override: When using shadow color, this allows light rays in addition to the shadow rays. (default off == no light rays, only shadow rays)<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space (c.f. section LuxCore)<br />
* New shape node "MergeOnDistance" (like Blender Merge by Distance)<br />
* Subdiv: (simple) crease management<br />
<br />
<br />
= BlendLuxHelper =<br />
* Adding BlendLuxHelper: A new helper, in the form of a Blender extension, which allows to configure the wheel that is imported by BlendLuxCore.<br />
* <del>Change installation mechanism to use bpy.utils.extension_path_user()</del> (Reworked within the scope of BlendLuxHelper)<br />
* <del>Added a Linux development shell script (optional utility for developers)</del> (replaced by BlendLuxHelper)<br />
<br />
= LuxCore =<br />
<br />
'''Coding/Backend'''<br />
* Subdivision: multithreaded version, in order to improve speed<br />
* Reduction of Boost footprint, replaced with standard equivalents available in C++20.<br />
* For the need of previous point: replacement of apple-clang by clang 20 on MacOS platforms<br />
* New target 'wheel-test' that builds a testing wheel in local build (<code>make wheel-test</code>)<br />
* Requirement checking in <code>make deps</code><br />
* luxrays: rename GetConfigDir as GetCacheDir and use XDG_CACHE_HOME according to specifications (@illwieckz)<br />
* Adapt CI pipelines to MacOS-15 runners (after deprecation of MacOS-13 runners on Github)<br />
* Remove direct access to Blender internal objects. Use Blender API instead, more stable.<br />
* Add support for Python 3.14 (and remove support for 3.9)<br />
<br />
'''Bugfix'''<br />
* Fix a bug leading to unstable brightness between renderings when using saved crashes (Credit to FELIX Render developers)<br />
* Fix volume evaluation in BiDir engine https://github.com/LuxCoreRender/LuxCore/issues/647<br />
* Fix various bugs when using orthographic camera with light tracing https://github.com/LuxCoreRender/LuxCore/issues/667<br />
* Fix various memory-related issues (leaks, potential access violations...). Modernize memory handling (to be continued)<br />
* Avoid crash if no OpenCL and/or Nvidia API is found<br />
* Fix several race conditions<br />
* Fixed an error where paused renderings can't be stopped anymore<br />
* 3D-mapping: Fix inconsistent behavior between local and random-local mapping https://github.com/LuxCoreRender/BlendLuxCore/issues/656<br />
* Add a clamping in SchlickBSDF to avoid (very small) floating point issues<br />
<br />
'''Features (of interest for users)'''<br />
* Subdivision: add an "adaptive" setting to select between adaptive refinement and uniform refinement<br />
* Make `pyluxcoretools` available again (in the wheels)<br />
* Apply the behavior of the BiDir engine w.r.t. shadow color mechanism to Path+Light tracing. <b>Breaking change for scenes using shadow color and light tracing (not BiDir)!</b> https://github.com/LuxCoreRender/LuxCore/issues/671<br />
* 2D-mapping: Add an option to allow rotation around the center of UV-coordinate space https://github.com/LuxCoreRender/BlendLuxCore/issues/644<br />
<br />
= LuxCoreDeps =<br />
* Dependencies updated to latest versions<br />
* Better dependency pinning (for nvrtc and conan-index)<br />
* Removed a workaround introduced in previous version (we used to build a fake wheel to get containerization)<br />
* OpenMP - MacOS: Use of homebrew OpenMP (up-to-date, compatible with clang 20) rather than Conan llvm-openmp (version 17...). As a consequence, for MacOS Intel, a version >= 13.0 is required.<br />
* Opensubdiv: tbb activation. As a consequence, for MacOS Arm, a version >= 14.2 is required.<br />
* OpenImageIO: deactivation of several image formats that seem unrelated to or unsupported by LuxCore: freetype, hdf5, ffmpeg, libheif, ptex, opencv. This removal spares both compilation time and build result size. Those formats are reactivable, in case they were missing.<br />
* OpenImageIO: To the contrary, activation of tbb option.<br />
* Embree: Upgraded to version 4.<br />
* libjpeg: Replaced with libjpeg-turbo</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2893Deploying LuxCoreRender2026-09-06T06:36:45Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the Branching Strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>DefaultVersion</code> parameter in <code>build-system/build-settings</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>release/X.Y</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>release/X.Y</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>release/X.Y</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2892Deploying LuxCoreRender2026-09-06T05:13:51Z<p>Howetuft: /* BlendLuxCore Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the Branching Strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>release/X.Y</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>release/X.Y</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>release/X.Y</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2891Deploying LuxCoreRender2026-09-06T05:13:27Z<p>Howetuft: /* Samples Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the Branching Strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>release/X.Y</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>release/X.Y</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2890Deploying LuxCoreRender2026-09-06T05:13:08Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the Branching Strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>release/X.Y</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2889Deploying LuxCoreRender2026-09-06T05:12:40Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the Branching Strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2888Deploying LuxCoreRender2026-09-06T05:11:54Z<p>Howetuft: /* Make sure you understand the Branching Strategy */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the Branching Strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2887Deploying LuxCoreRender2026-09-06T05:11:23Z<p>Howetuft: /* Prerequisites */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Make sure you understand the Branching Strategy ==<br />
<br />
This procedure stems from the Branching Strategy, which takes precedence over it.<br />
See [[Branching and Version Control]]<br />
<br />
Before releasing, take the time to make sure you fully understand the branching strategy as a whole, and in particular the various rules that apply to the release process, including:<br />
* Building releases on a dedicated branch, so as not to interrupt development in the meantime<br />
* The prohibition against developing on release branches<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2886Deploying LuxCoreRender2026-09-06T05:03:01Z<p>Howetuft: /* Release Branch creation */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
Remark: <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>, which do not need to be at HEAD, as soon as it provides the expected features for the release.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2885Deploying LuxCoreRender2026-09-06T04:59:00Z<p>Howetuft: /* Procedure */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Release Branch creation ==<br />
<br />
If not done before, create branch <code>release/X.Y</code>, to host the release, by forking <code>main</code>.<br />
<br />
A few remarks:<br />
- <code>release/X.Y</code> can be cut <i>at any convenient point in <code>main</code> history</i>.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2884Deploying LuxCoreRender2026-09-06T04:54:31Z<p>Howetuft: /* Wheels Release and Deployment */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>release/X.Y</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2883Deploying LuxCoreRender2026-09-06T04:53:57Z<p>Howetuft: /* Pre-Flight Review */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
Apply [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2882Deploying LuxCoreRender2026-09-06T04:53:47Z<p>Howetuft: /* Pre-Flight Review */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See [[#Prerequisites]] above.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2881Deploying LuxCoreRender2026-09-06T04:53:32Z<p>Howetuft: /* Pre-Flight Review */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See [[#Prerequisites]].<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2880Deploying LuxCoreRender2026-09-06T04:50:51Z<p>Howetuft: /* Prequisites */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prerequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See above (prerequisites).<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2879Deploying LuxCoreRender2026-09-06T04:48:52Z<p>Howetuft: /* Define Version */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version(s) ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See above (prerequisites).<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2878Deploying LuxCoreRender2026-09-06T04:48:34Z<p>Howetuft: /* Check LuxCore is Buildable */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Check LuxCore is buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See above (prerequisites).<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2877Deploying LuxCoreRender2026-09-06T04:48:22Z<p>Howetuft: /* Prequisites */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Check LuxCore is Buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Ensure that there is no regression ==<br />
<br />
Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See above (prerequisites).<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2876Deploying LuxCoreRender2026-09-06T04:46:29Z<p>Howetuft: /* Pre-Flight Review */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Ensure LuxCore is Buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
<br />
See above (prerequisites).<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2875Deploying LuxCoreRender2026-09-06T04:45:41Z<p>Howetuft: /* Sufficient space on PyPI and PyPI-test */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Ensure LuxCore is Buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Ensure space is sufficient on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2874Deploying LuxCoreRender2026-09-06T04:45:12Z<p>Howetuft: /* Version Consistency */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Ensure LuxCore is Buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Define Version ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2873Deploying LuxCoreRender2026-09-06T04:44:49Z<p>Howetuft: /* Change Log Readiness */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Ensure LuxCore is Buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Prepare Change Log ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Version Consistency ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2872Deploying LuxCoreRender2026-09-06T04:44:32Z<p>Howetuft: /* LuxCore Buildability */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== Ensure LuxCore is Buildable ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log Readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Version Consistency ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2871Deploying LuxCoreRender2026-09-06T04:44:05Z<p>Howetuft: /* Consistent Version Numbers */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== LuxCore Buildability ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log Readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Version Consistency ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2870Deploying LuxCoreRender2026-09-06T04:43:49Z<p>Howetuft: /* Change Log readiness */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== LuxCore Buildability ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log Readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Deploying_LuxCoreRender&diff=2869Deploying LuxCoreRender2026-09-06T04:42:30Z<p>Howetuft: /* Prequisites */</p>
<hr />
<div>= Audience, Definitions and Scope =<br />
<br />
This document is intended for <i>LuxCoreRender administrators</i> only.<br />
<br />
The process requires that the administrator running Release and Deploy be:<br />
* granted with sufficient rights on LuxCoreRender repositories on Github, including running actions, producing releases etc.<br />
* granted with sufficient rights on LuxCoreRender repository on PyPI and PyPI-test, including adding and deleting versions<br />
* skilled enough in Github administration and, especially, able to run Github actions<br />
* and skilled enough in PyPI administration<br />
Please check that you meet these criteria before reading further.<br />
<br />
<br />
In this document:<br />
* <i>Releasing</i> refers to the process of finalizing a version of LuxCore, i.e. defining a state of LuxCore which can be made available to end-users.<br />
* <i>Deployment</i> refers to the process of making a new release of LuxCoreRender available to end-users.<br />
<br />
<br />
The scope of Deployment includes the following components:<br />
* <b>Python Wheels</b> (aka <code>pyluxcore</code>)<br />
* <b>Samples</b> (aka <code>luxcoreui</code> and <code>luxcoreconsole</code>)<br />
* <b>BlendLuxCore</b><br />
<br />
Please note we deliberately exclude the dependencies (aka <code>LuxCoreDeps</code>) from the deployment scope. Indeed:<br />
* Dependencies are not intended for end-users, so deployment is not applicable.<br />
* Up-to-date dependencies are necessary for LuxCore development and tests, so they should have been released for a while when LuxCore deployment occurs.<br />
<br />
= Prequisites =<br />
<br />
== LuxCore Buildability ==<br />
<br />
This is normally ensured by the branching strategy. However, it doesn't hurt to double-check.<br />
<br />
The procedure requires that targeted LuxCore components be <i>buildable</i> by <i>Continuous Integration</i>.<br />
<br />
This can be checked by running the following Github Actions:<br />
* Wheels: <code>LuxCore Python Wheel Builder</code> (in LuxCore repository)<br />
* Samples: <code>LuxCore Python Sample Builder</code> (in LuxCore repository)<br />
* BlendLuxCore: <code>BlendLuxCore Build Bundle</code> (in BlendLuxCore)<br />
<br />
Please check the components meet those requirements before any Release/Deploy task is engaged.<br />
<br />
== Change Log readiness ==<br />
<br />
At a certain point in the process, a change log will be expected: you should have prepared it beforehand. Note this can be done afterwards, however.<br />
<br />
== Consistent Version Numbers ==<br />
First, note you'll need 2 version numbers:<br />
* One for LuxCore<br />
* One for BlendLuxCore<br />
There is no reason why these 2 version numbers should be the same.<br />
<br />
These version numbers must enforce Semantic Versioning, as stated in [[Building_LuxCoreRender | Building LuxCoreRender]]<br />
<br />
Please note also that <b>the version numbers should not have been used in anyway in previous releases</b>. It is particularly important for PyPI (and PyPI-test), that will reject any upload declaring a version that has already been in use before, event for a short time.<br />
<br />
== Sufficient space on PyPI and PyPI-test ==<br />
<br />
The space on PyPI and PyPI-test is limited to 10GB (as of now, 2026-04-19).<br />
<br />
At first glance, this could look quite comfortable, however we release 20 wheels each time (about 80-100MB each): the space required for one release is about 1.5GB. As a consequence, the space sufficiency must be checked each time a version has to be deployed.<br />
<br />
Nota: this check is <i>critical</i> and should be done with care. If the upload to PyPI is interrupted halfway, for instance by lack of space, the version number will still become no more available.<br />
<br />
= Procedure =<br />
<br />
== Pre-Flight Review ==<br />
As stated above, before starting the core procedure, carry out the following actions:<br />
<br />
* Ensure the default branches are up-to-date<br />
* Check LuxCore buildability: run the 3 actions listed above.<br />
* Render all available test scenes and compare the results to previous versions. Delete the OCL/CUDA kernel caches before rendering. If there are visible changes, verify if they are expected due to backend changes introduced in this version.<br />
* Ensure the change log is available<br />
* Define and check Release Version Numbers (one for LuxCore and one for BlendLuxCore): they should have been neither allocated before, and the LuxCore should not have been used on PyPI.<br />
* Check the space on PyPI and PyPI-test. If not sufficient, clean oldest versions.<br />
<br />
Afterwards, you are ready to start the core process.<br />
<br />
== Wheels Release and Deployment ==<br />
<br />
* Set the <code>version</code> parameter in <code>build-system/conan/conanfile.py</code> to the targeted version number for LuxCore.<br />
<br />
* Run action <code>LuxCore Python Wheels Releaser</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>checked</i><br />
<br />
This will build the wheels and create a release in draft mode.<br />
<br />
<br />
* Open the draft release and set its status to <code>prerelease</code> or <code>latest release</code>. Also, insert the change log in the release text. Save the release.<br />
<br />
At this stage, the wheels are released, but we still have to deploy them through PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <i><code>master</code></i><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>checked</i><br />
This will upload the wheels to PyPI test (deployment - test).<br />
This is a test step, to check everything is fine before uploadig to real PyPI.<br />
<br />
<br />
* Run action <code>LuxCore Python Wheels Publisher</code>, with the following settings:<br />
Branch: <code>master</code><br />
Version: <i>the version number you selected before</i><br />
Run on PyPI test: <i>unchecked</i><br />
This will upload the wheels to PyPI (deployment).<br />
<br />
<br />
At this stage, if everything succeeded, wheels are available for any user, with <code>pip install pyluxcore == <version> </code>. You may want to test and/or have a look on PyPI.<br />
<br />
== Samples Release and Deployment ==<br />
<br />
Nota #1: This step should be skipped for alpha releases, as the vast majority of alpha testers use Blender for testing. No need for samples in this context...<br />
<br />
Nota #2: We assume the wheels have just been released, so that it is possible to reuse their build artifacts. This will be done by clearing 'rebuild all' in the following action.<br />
<br />
<br />
* Run Github action named <code>LuxCore Samples Releaser</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>unchecked</i><br />
Rebuild all: <i>unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== BlendLuxCore Release and Deployment ==<br />
<br />
Important warning: BLC should <b>not</b> be released while related wheels have not been deployed yet. Indeed, <code>pyluxcore</code> version must be known before starting any release or deploy action of BLC.Once that requirement is met:<br />
<br />
<br />
* In <code>luxloader/__init__.py</code>, set <code>PYLUXCORE_VERSION</code> to the version of related <code>pyluxcore</code>. The version to use must be strictly the same as the one that appears on PyPI. Please check syntax carefully, as PyPI may slightly modify version number when uploading.<br />
<br />
* In <code>blender_manifest.toml</code>, set <code>version</code> parameter to the targeted version of BLC. Caveat: this version can differ from pyluxcore version defined above.<br />
<br />
* Commit your changes and push to BlendLuxCore repository, if needed.<br />
<br />
* Run Github action named <code>BlendLuxCore Create Release</code>, with the following settings:<br />
Branch: <i>main</i><br />
Version: <i>the version number you selected before</i><br />
Update existing release (if any): <i>Unchecked</i><br />
<br />
At this stage, a <i>draft release</i> should have been created.<br />
<br />
* Open the draft release, insert change log and set release status to <i><code>prerelease</code></i> or <i><code>latest release</code></i>.<br />
<br />
* For latest releases, publish the files on the website<br />
<br />
== Documentation and Announcements ==<br />
<br />
Part of the process of releasing a software is to create a proper documentation, both to support future development and to provide users with the necessary information to work efficiently with the software.<br />
Furthermore, the final step after release and deployment is to announce the release to the community.<br />
<br />
The following items are currently - as of v2.11 - particularly important and should be checked and well considered before a final release:<br />
* This wiki, particularly<br />
** Release notes<br />
** FAQ entries<br />
** Updates to the build process<br />
** Description of new features, API and SDL documentation<br />
* The project website<br />
** particularly the downloads section<br />
* The README files in all active code repositories<br />
* The AUTHORS file and credits list<br />
** specifically regarding 3rd-party modules that may have been added to the code<br />
* Announcement on the forums<br />
* Announcement in the discord channel<br />
* Announcement on Blenderartist, ...<br />
<br />
During the various release steps (alpha, beta, release candidate, stable and subsequent bugfixes), the different items may be completed to varying degrees, reaching maturity towards the stable release. The following are suggestions based on past experience. You can always look at past releases for inspiration.<br />
<br />
==== Alpha ====<br />
* Update the release notes<br />
* Update the API/SDL description<br />
* Check the authors file and credits list<br />
* Brief GitHub release notes with warning labels about stability<br />
* Announcement on the most active user channels<br />
* Decide on final tasks/known bugs that shall be fixed during alpha/beta phase<br />
<br />
==== Beta ====<br />
* Keep updating release notes and API/SDL documentation<br />
* Update the Readme files in the code base<br />
* Start preparing a summary release notes for the GitHub release<br />
* Announcement of beta phase on more community channels<br />
* Complete all tasks for features/known bugfixes<br />
<br />
==== Release Candidate ====<br />
* All documentation shall be updated fully<br />
* Update FAQs with feedback from alpha/beta phase<br />
* Double check authors and credits<br />
* GitHub release notes still should contain a warning label<br />
* Start preparing stable release announcement messages for all channels<br />
<br />
==== Stable (X.Y.0) ====<br />
* Double-check all documentation<br />
* Prepare the final release notes summary<br />
* Create the release<br />
* Update the download section on the website<br />
* Create the announcement post on the forums<br />
* Finally, announce on Discord and optionally other sites<br />
<br />
==== Bugfix (X.Y.Z) ====<br />
For bugfix releases, prepare the following<br />
* Update the Release Notes on this wiki<br />
* Prepare a summary release notes targeted at users<br />
** This needs to only include the incremental changes from the previous version<br />
* Make a short announcement on the same channels as the for the stable release</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2868Branching and Version Control2026-09-06T04:31:26Z<p>Howetuft: /* Release process */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2867Branching and Version Control2026-09-06T04:29:52Z<p>Howetuft: /* Release process */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b>. Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2866Branching and Version Control2026-09-06T04:18:37Z<p>Howetuft: /* Release process */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2865Branching and Version Control2026-09-06T04:17:48Z<p>Howetuft: /* Continuous integration */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2864Branching and Version Control2026-09-06T04:17:23Z<p>Howetuft: /* Branch naming */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2863Branching and Version Control2026-09-06T04:16:58Z<p>Howetuft: /* Release process */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2862Branching and Version Control2026-09-06T04:12:09Z<p>Howetuft: /* Long-lived branches */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2861Branching and Version Control2026-09-06T04:11:50Z<p>Howetuft: /* Long-lived branches */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2860Branching and Version Control2026-09-06T04:11:21Z<p>Howetuft: </p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability for LuxCore varies, which means that some development tasks may take time (and the related development branches may remain active for a long time) as we are busy elsewhere. To the contrary, when we are available, we should not be hampered by excessive admin tasks (git configuration and so on).<br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This should apply to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare.<br />
<br />
Thus, the first rule is <b>Avoid long-lived branch</b> when possible. There are a few techniques to do so:<br />
* Feature flags for anything mergeable in pieces: https://trunkbaseddevelopment.com/feature-flags/<br />
* Branch by abstraction (https://trunkbaseddevelopment.com/branch-by-abstraction/). <br />
<br />
If there is no other possibility but to create a long-lived branch:<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2859Branching and Version Control2026-09-02T01:52:32Z<p>Howetuft: /* Release process */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2858Branching and Version Control2026-09-02T01:51:05Z<p>Howetuft: /* Release process */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, but also to release bug fixes.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2857Branching and Version Control2026-09-02T01:35:23Z<p>Howetuft: /* Branch naming */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. As a counterpart, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code> : for new feature development<br />
* <code>fix/*</code> : for bug fixing<br />
* <code>refactor/*</code> : for code refactoring<br />
* <code>release/X.Y.Z</code> : for new release<br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2856Branching and Version Control2026-09-01T11:29:37Z<p>Howetuft: /* Main branch */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. As a counterpart, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code><br />
* <code>fix/*</code><br />
* <code>refactor/*</code><br />
* <code>release/X.Y.Z</code><br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2855Branching and Version Control2026-09-01T06:13:15Z<p>Howetuft: /* Preliminary considerations */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch. Release points are tags of <code>main</code>.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. As a counterpart, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code><br />
* <code>fix/*</code><br />
* <code>refactor/*</code><br />
* <code>release/X.Y.Z</code><br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2854Branching and Version Control2026-09-01T06:12:57Z<p>Howetuft: /* Strategy */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, wdeploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch. Release points are tags of <code>main</code>.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. As a counterpart, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code><br />
* <code>fix/*</code><br />
* <code>refactor/*</code><br />
* <code>release/X.Y.Z</code><br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetufthttps://wiki.luxcorerender.org/index.php?title=Branching_and_Version_Control&diff=2853Branching and Version Control2026-09-01T06:12:42Z<p>Howetuft: /* Strategy */</p>
<hr />
<div>The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.<br />
<br />
<b>Status: PROPOSAL</b><br />
<br />
= Preliminary considerations =<br />
<br />
A few considerations should be kept in mind:<br />
* We are a very small core team. Branch strategy should be light and agile.<br />
* However, we also want a frame structured enough to avoid git pitfalls (merge conflicts and so on), in which we can welcome occasional contributors and, why not, some other core developers.<br />
* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.<br />
* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time). <br />
* We are also dependent from other environments: in particular, wdeploy on PyPi, where releases are immutable<br />
<br />
= Strategy =<br />
<br />
Our strategy is inspired by <b>Trunk-Based Development</b> (TBD), as described here: https://trunkbaseddevelopment.com/.<br />
<br />
We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.<br />
<br />
<pre><br />
main ─────●────●─────────●────●────●──→ (always stable, always releasable)<br />
\ \<br />
feature/big-thing feature/another-thing<br />
(lives for weeks, (short, merges fast)<br />
synced regularly)<br />
</pre><br />
<br />
This applies to all LuxCoreRender repositories, and especially:<br />
* LuxCoreDeps<br />
* LuxCore<br />
* BlendLuxCore<br />
<br />
== Main branch ==<br />
Requirements:<br />
* <code>main</code> is the default branch of the repository<br />
* <code>main</code> must always be kept <b>stable/releasable:</b><br />
** Linear history is required. No squash, rebase etc.<br />
** Straight push is discouraged (though not totally forbidden, see below)<br />
** PRs must ensure a good level of completeness<br />
* Releases are built from the <code>main</code> branch. Release points are tags of <code>main</code>.<br />
* Releases are immutable (PyPi)<br />
* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.<br />
<br />
<br />
Then, two branch lifespans, both fine:<br />
<br />
* Short-lived (hours–days): bug fixes, small features — developers required to merge fast.<br />
* Long-lived (weeks–months): big features — developers required to give extra care to keep them alive, so they don't rot.<br />
<br />
== Short-lived branches ==<br />
<br />
Short-lived branches are those which won't live more than a week. This kind of branch should be preferred whenever possible. Requirements are:<br />
<br />
* Create branch systematically, avoid direct push, even for core developers. See below.<br />
* Delete branches after merge to keep things tidy.<br />
* Reclassify into long-lived branch if duration exceeds week, and apply long-lived branch rules<br />
<br />
<br />
Why should core devs create branches systematically?<br />
<br />
In our scheme, <code>main</code> must always remain stable/releasable. But with direct push, in case of CI failure, merging will go ahead anyway and <code>main</code> will be broken. That's why <i>direct push is discouraged even for core devs</i>.<br />
However, it will not be totally deactivated (for core devs), as it could be needed in emergency situation (hotfix).<br />
<br />
Moreover, avoiding direct push and relying on pull request allows minimal cleaning before merging (like squashing), and also comments, review by peer etc.<br />
<br />
== Long-lived branches ==<br />
<br />
Keeping long-lived branches alive and mergeable is the actual hard problem — a branch that sits for 6 weeks while <code>main</code> moves on becomes a merge nightmare. A few techniques:<br />
<br />
* <b>Avoid long-lived branch</b> when possible: rather use feature flags for anything mergeable in pieces. If a big feature can be built incrementally, merge the scaffolding into main early behind a flag (if FEATURE_X_ENABLED:) rather than keeping it all on a branch. This is the single best way to avoid branch drift — the branch just stops existing. GitHub, GitLab, and most large projects lean on this heavily for exactly this reason.<br />
* Regularly merge <code>main</code> into the feature branch (at least once a week, and whenever <code>main</code> changes meaningfully). Don't wait until the end to reconcile. Whoever touches the feature branch next does the merge.<br />
* Open Draft/WIP PRs early, even if the feature won't land for months. Gives visibility to the other maintainer and any contributors, invites early feedback before you're deep in a direction, and signals "someone's working on this" so others don't duplicate effort.<br />
<br />
== Release process ==<br />
The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.<br />
Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.<br />
Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.<br />
<br />
That may be the case, for instance, in LuxCoreDeps.<br />
<br />
In a more general way, however, there is often a need for release branch, due to bug-fixing.<br />
<br />
That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.<br />
<br />
The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch. Developers only commit to <code>main</code>. As a counterpart, release process is not blocking and post-release development can go on even if release has not been completed.<br />
<br />
In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.<br />
<br />
<br />
For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/<br />
<br />
== Branch naming ==<br />
Branch names should be formatted as <code>type/short-description</code>, to keep history scannable.<br />
<br />
Available types are:<br />
* <code>feature/*</code><br />
* <code>fix/*</code><br />
* <code>refactor/*</code><br />
* <code>release/X.Y.Z</code><br />
<br />
== Continuous integration ==<br />
WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:<br />
* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasabiloty are kept.<br />
* In a weekly build: run extensive tests to ensure non-regression.</div>Howetuft