A model proposal for releasing #144
Comments
|
For this whole project I would set the bar as high as doing something that would be in the long run be competitive with commercial offerings such as Serum and Omnisphere. In order to reach that we need a solid way how develop this. No reason to set bar lower than that with such a good mixture of differing talent :) |
|
We definitely need @kurasu to chime in here also. I agree with rc branches. That's a smart way to work. I don't know if we need a separate repo for full release but definitely branches for those also make sense. I worry we are short manpower to do this like a full blown professional offering though. Each of us will come and go etc... But it is a really cool synth. Glad to have it in my rig! |
|
Yes, with I'm thinking with the long run goal like few years of timeline :) With a good release model things will improve without you even noticing it. |
|
Agree. @kzantow s work on a pipeline will be an important part of this too. It would be lovely to have an rc-1 ready bit of software too. The synth sounds great and has a really clever modulation architecture. I think I will use it quite a lot! |
|
One of my all time favs use it for majority of synths http://www.ektoplazm.com/free-music/pavel-svimba-space-babuska |
|
Ok I’m having fun hacking on surge, but the fact that I also got a rec for “Finnish psychedelia at its best” is a wonderful little bonus. I will definitely take a listen! |
|
Yeah, it is one of the best releases ever when it comes to groovy housy twisted daytime psytrance. The guy who made it pinged me to do something to this project. That is why I'm here :) For what I'm concerned, helping with this project is my tribute to a music genre called suomisaundi where this synth has been widely used. Oddball, mental, Finnish version of psytrance. |
|
Something we do in another OSS project I'm a part of: just create release branches. Master should always be bleeding edge, when we want to do a release, then create something like |
|
Also, i'm just about done being able to build/release 64-bit osx and windows installers. Hit a snag with windows bash + sed not using the same expression syntax as mac. :-/ |
|
... but I'm currently uploading binaries into my forked git repo and just updating a |
|
In Linux, fixes go always first go to master (if you imagine it was just one Git, actually goes to subsystems master) and from there it is backported stable releases. |
|
... just pointing out the difference. In some other issue there was discussion about 1.7 so thought to start the conversation. I'm happy with any model that works but maybe it would be the time to carve something, maybe even document it? |
|
Yeah, I find the aforementioned fix on branch strategy to be easy for small projects, because you can always merge up to master and make sure master has all fixes. Cherry-picking fixes back into release branches is okay, just a little harder to follow what's there vs. master, from what i've seen. |
|
... and sometimes you already have something fixed on master (or no longer relevant) so cherry-picking back to a release branch, then merging the commit sha with no changes still keeps the 'always-merge-to-master' strategy working easily to make sure all fixes are there |
|
@kzantow that strategy WFM. Thanks for explaining. |
|
I’m glad to follow your guys lead on this. Have worked lots of ways over the years. Any plan that works four our team of volunteers is great. Maybe it’s time for a doc/Developer.md or some such laying out whatever you two think is right then see if @kurasu agrees. |
|
@baconpaul good idea, probably also laying out the actual build/release portion, too. that way it won't get lost in issue comments ;) |
|
@kzantow I think we have here everything needed. At this point could be just a section in README.md? Post that we just follow it or create a new issue if there are major hug ups... |
|
@jsakkine Sounds good to me, I don't have a very strong opinion as long as its clear. |
|
Cool, I'll scrape something out based on mine and @kzantow's comments so that we have a framework to do 1.7 release. |
|
Have not forgotten about this. Next on list after build stuff. |
|
FYI, I hacked together automated builds, finally. the releases here are built on azure pipelines: https://kzantow.github.io/surge/ (please remember this is just a temporary spot for testing the automated builds...) any verification that the builds work properly would be great ;) #97 |
|
That's great! I could set this up on kurasu/surge then too when I have some time, just let me know what I need to do.. For releases we might want to build somewhere else, so someone can be the official signer of the VST & Audio Unit licenses and so we can sign the binaries & installers. |
|
@kzantow, do you have any idea if there could be a way to try autobuild all PRs and automatically report an error if a compilation issue arises? |
|
BTW, would be awesome addition to see the build date and time on the page :) |
|
Fantastic @kzantow how cool. Curious- what do oss projects do for licensing the plugin layers generally? |
|
BTW should we just call the first open source release simply as Surge 2, and one after that as Surge 3. Like Firefox/Chrome style rolling releases? I think it would be a good fit for this kind of project. |
|
Maybe some really short support period for old releases after a new one has been released (like one month with this manpower). Everyone uses anyway the latest. |
|
I'd even go far as proposing that no support for old releases, not even a month. If that causes problems, then it can be revisited later. Then we can develop mostly to master and backport fixes between master and latest version branch. I'd say that it is the only model where we can scale ATM. |
|
@jsakkine i feel like if it is called Surge2, we will be inundated by ppl grilling/flaming us for not fixing old bugs or adding amazing new features we had no idea they wanted. |
|
Chrome is at version 71 :) It is easy model to follow and welcoming to new developers. It is something we can scale. After version 2 we can do timely releases (like every three months). Auto-update mechanism would help on what you described. Timely release could be just taking whatever has made to the master and call it release i.e. |
|
I think for now lets aim for completing the "1.6 release" (I accidentally called that a "1.7 release" in a ticket a while ago) which was contemplated in the source which @kurasu kindly gave the community when he released this in september. I was thinking, though, we should have a list of things which are in that release so we could stamp it! |
|
At least I would like to eventually want do something more interesting than think about major/minor releases and whatnot. This is not really a piece of mission critical software. The release model should be considered from that perspective IMHO. I dare to say that what I'm proposing is what many potential new developers would like and users want :) I'm fine calling the very first as 1.6 (or actually I think it is a good idea) and then go more wild. The branching and maintenance model could start from the Surge 1.6 (have Surge-1.6 branch with the forementioned amount of support i.e. as long as it takes to get Surge 2 out). And yeah, naturally Surge 1.6 cannot be a timely based release. It takes as long as it takes. We should be ready for post-1.6 time and preferably document it, which I promised to do. I like simple and stupid when there is no reason not be simple and stupid :) Maybe we should make automatic updates at least on Windows a release goal? That cannot be rocket science (never done it though). |
|
Yeah, and definitely automatic build checks for all incoming PRs is something that would be required because you eliminate two potential points of failure by doing that for builds: the developer and the maintainer. |
|
@baconpaul: I can check #160 tomorrow unless it has been already fixed. Would be a good exercise to learn a bit about Surge's GUI side for me :) |
|
I like the idea of 1.6 can check for updates and pop a dialog. When we wrangle the 1.6 requirements into issues can we make sure to add that? We’d need a place where official releases lived and to know a version number but it’s not that hard at least to tell the user they can update. |
|
Thanks! I am most of the way there but if I don’t finish it I will push what I have to my repo so you don’t have to start from scratch. |
|
I carve some kind of PR to README.md about potential release process. Nothing that I expect or even want to be pulled soon. This has been a fruitful and good discussion so far but I think now it is time actually do something before this starts going cycles :) |
I'm 99% sure there's a way to do this. I'd probably just run the build for PRs and skip making the installers unless there's some better way to make/upload temporary releases. |
|
@jsakkine I think the integer version number scheme makes sense now that it's open-source, it will remove the need to make decisions about it for each release and keeps things simple. When it was commercial there were other things to consider, paid updates for major releases being the main one. |
@kurasu: nothing to do, really, just sort out who is allowed to release VST2/3 so they can be the official releaser (and AU, if there are other requirements). And then figure out where to actually upload the releases (I'm dumping them in git, the
It seems like this could be done fairly easily by just making one person who has appropriate Steinberg license agreements the official "releaser", probably just by way of whatever name/company was used for the agreement in the first place. |
I'm on the flip side a bit here. I think it would confuse users to see Surge 2, Surge 3, etc., as pretty much all software plugins have major releases which could be breaking. I'd be quite happy to see a |
|
This thread will go forever and there is no right answer and all these suggestions are great - as in they would all work - which is why I want to stay out. But... Have we considered dated versions? So Surge-2019.01 And then each 2019 release we tick the 01 to 02? Avoids the “surge2 doesn’t have ...” and is nicely descriptive. We have branches like surge-2019-01-rc and surge-2019-01-released Just a thought! |
|
Not laughing because I think that the proposal is necessarily bad at all. Just seeing a spiral here :) I'll make a PR (after looking at the bug that you pointed out and even after landing the first cmake changes) and you can then describe the various ways it sucks :) |
|
OK! Look forward to reading it when I'm back from travels. I got most of the way on #160 but there's still work to do also - see that issue for details. And happy new year everyone! Fun couple of weeks getting this into shape!! |
|
And just realized that it is useless up until the 1.6 is out so I think we could merge something that is not perfect to master tree too without much concern. Then when new ideas pop up, one can send a new PR. I think for this issue "something in that is not perfect" is a good close criteria. |
|
Hey I think we are doing all the things in this ticket now with the auto builds and the branch builds when we finally make a release branch right? I’m going to close it but if you disagree please tag a comment on and I will reopen it |
Model that I've had in mind for releasing new "feature" releases:
The mode for stable releases:
The text was updated successfully, but these errors were encountered: