-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SItoA for Arnold 5.2 to master #29
Conversation
and moved and renamed some vars
and make the output field read only
@sjannuz When you have merged the remaining open PRs I feel it's time to go master. What do you think? |
Hi @JenusL , sure, I just need a couple of hours to dedicate to this. |
Renames deprecated gobo parameters
Arnold Denoiser
Thank you so much @sjannuz for taking the time to finally go master! |
Hi @JenusL , I should have some time before the end of this week. Thankyou for all your work. |
|
I have the addons ready, built against 5.2.2.1. I've packed different addons for Windows and Linux, since each is now about 370M. |
Awesome! I reached out to si-community to see if anyone can test on Linux. I will reach out to some friends tomorrow morning as well. |
I wrote down a changelog as well if you want to use it for the release: https://gist.github.com/JenusL/a8ac760ebd867356035f5e2913990254 |
I must say that it has been very fun to code for this project so far. The code is so nice and structured that it has been a breeze to navigate and read.
Now after #28 has been merged into develop I feel that it's time to merge this into master and make a real release. Or should we include something more?
Before we merge, lets discuss how we should deal with versioning and branching going forward.
I changed the versioning to match Arnold version because that just makes more sense to me. But that goes away from the old versioning. How do you guys feel?
Last version of SItoA was 4.1. Is it ok to jump to 5.2 and sync with the Arnold version or should we name this 4.2 and stick with the old versioning that's unrelated to Arnold version?
This goes together with branching a bit. If we should remove the develop branch and always PR to master, we would probably like to version up on every PR whether it's a new feature or a fix. That can end up being a lot of versions. I think that means someone at AD needs to be responsible for the versioning because it probably needs to be done as a separate commit directly to the branch after a batch of PRs has been merged.
What do you think?