Allow continuous use of master version

jasp00 commented 7 years ago

AFAIR, years ago, when we developed LMMS with SVN, without pull requests, and checking only that it worked on our Linux distros, we could make songs with the master version. We could make a continuous use (kind of an LMMS equivalent to Debian Unstable) and benefit from each bug fix and new feature. It was not officially supported, but chances were very high our songs would be upgraded. We committed immediately, thus we could easily adjust the version number.

It would be nice to have that feature back. So, if we were to implement it, how would you do it if not following my suggestion at #3281?

It's overkill. We only need to upgrade with RCs at the most granular of levels. We don't release any more granular than RCs, it's plenty.

But we do not release often, right? We wait months. In the past, we did not have to wait. Why cannot we offer this possibility?

tresf commented 7 years ago

I'm an avid fan of nightliies. In regards to project upgrades we need a hard line in the sand for sanity's sake. The solution will always suffer failure to see the future (e.g. How do I detect the version which this upgrade applies to?). If we make a bot for this it'll fix the coder's paradox but introduce micro-build granular upgrade functions. Maybe this is the way to go, but I feel the upgrade functions should be clear and easy to read. I don't want anyone running a nightly to expect 100% compatibility, so I feel the use-case is too granular and clutters the line we should be drawing.

That said, if there are enough use-cases to justify, I'm all ears.

jasp00 commented 7 years ago

Then let us wait until there is more demand.

DeRobyJ commented 7 years ago

I'd really like to have more beta releases, because as a mainly windows user, unable to compile for windows, each time a version has a bug I'll have to wait a lot before getting the fix, and maybe it was already fixed some days after the launch.

If I were a linux user I'd just compile the latest (because I set it up and it's really just a command, other users wouldn't).

Just an example: RC2 has this bug that sometimes a particular project crashes on opening. You pretty much lose a project for no reason, and you need to revert, installing an older version, saving the project, then re-upgrading and hope the bug is no more. Maybe this bug was already fixed, but there's no new release for windows so I can't use it.

So yea, I'm a fan of frequent betas Actually I don't understand why we call it "Release Candidate" even when we know there are things left, I thought a Release Candidate was, yea, a good candidate for the final stable version.

tresf commented 7 years ago

I thought a Release Candidate was, yea, a good candidate for the final stable version.

Please do not criticize the release process unless you want to get your hands dirty and help. The RCs ARE stable. Master was a complete mess when Vesa left and it's taken us literally years to fix the crashes it introduced.

The project-opening bug wasn't immediately obvious and many bugs like these only surface through a lot of testing. The RC process is for that. It's for people who can live with bugs and want to help the project. This bug report is a perfect example of that.

In regards to more frequent Windows builds.... If we can get our Windows-building-on-Windows working better, that would be a good option, but it's not that good yet, so we still rely on Ubuntu 12.04 or Ubuntu 14.04 for making them. (BTW - Ubuntu 14.04 is free, runs in a VM and our documentation is pretty easy to follow).

TL;DR - Nightly builds are the way to go, they just take some time to setup properly. For example, if we don't purge old nightly builds, we'll be using 30GB per year for Windows 32/64 and Mac builds. If we start making packaged Linux builds, it would be 40GB per year.

jasp00 commented 7 years ago

Nightly builds are the way to go, they just take some time to setup properly.

Do you know about any service available? If not, this could be another automated task.

tresf commented 7 years ago

Do you know about any service available? If not, this could be another automated task.

My first thoughts are Travis-CI. It does releases for us already. I'm not sure where to put the files (and/or tags) so that they don't clutter our stable releases but it would ensure the nightlies are built from an environment identical to our stable.

Another option is to leverage our hosting provider, NetworkRedux for this, but I'm not sure it's a good use of the webserver CPU and it's running 12.04, which is approaching EOL.

foo@bar:~$ ubuntu-support-status
Support status summary of 'evs.lmms.io':

You have 3 packages (0.5%) supported until August 2018 (18m)
You have 502 packages (91.1%) supported until April 2017 (5y)

You have 2 packages (0.4%) that can not/no-longer be downloaded
You have 44 packages (8.0%) that are unsupported

jasp00 commented 7 years ago

My first thoughts are Travis-CI.

Mine too.

DeRobyJ commented 7 years ago

Please do not criticize the release process unless you want to get your hands dirty and help.

I'm not criticizing the process, I'm saying the name may lead to confusion. Maybe I failed to explain it well: why calling the current one a "Release Candidate" if we have some theme updates missing? I know it requires time, I'm not talking about that, I'm talking about the name, that's all.

I do have a copy of linux, KXStudio, and i can compile on that, again I'm not criticizing, I don't do VM and that's my choice, I'm talking about the general user who wants to use the latest features but has to deal with some particular bugs that might already be fixed. I'm not saying it's totally wrong, I'm saying that nighly builds would be better and I'd be really happy if it happens.

I'm sorry if sometimes my bad English make me say things in a negative manner, it's not my intention.

tresf commented 7 years ago

why calling the current one a "Release Candidate" if we have some theme updates missing?

A release candidate is a snapshot in time. All releases are a snapshot in time. They're tagged "line in the sand" -- so to speak -- releases that represent the state of the software at the exact moment they're released.

The release process takes time. Here are the release notes for RC2. I'm not exactly sure what you're asking here, since the RC will always fall slightly behind the closed bugs. Limiting the number of RCs helps us approach a sane expectation for the stable release.

Historically, nightly releases have suffered more instability since in previous years our master branch was used as a sandbox for untested, unfinished and unstable features. Only recently with the 1.2 release have we stopped the floodgates of breaking features to our master branch making it finally eligible for a rolling-release. We may be able to pull this off if we stop breaking things.

But I still think your complaints are more around "why not release RC3" versus "why call it a Release Candidate". I think the point under all of this is there are some important changes since RC2 that could benefit from a new RC.

Here's what is waiting on RC3: https://github.com/lmms/lmms/compare/v1.2.0-rc2...master

DeRobyJ commented 7 years ago

I see. If that has been the case of nightlies, then I wouldn't probably use them, maybe only to fix some bugged projects and then revert to the RC.

I'm not sure where to put the files (and/or tags) so that they don't clutter our stable releases

We might have one of us keeping them on his fork. I did take a build from yours for a while, before RC2. But I don't think it's appropriate...

tresf commented 7 years ago

We might have one of us keeping them on his fork.

I too was thinking about a forked copy but it really doesn't have any advantages over an unassociated mirror. The way the project is managed, there are administrators and a backup service account over the repository, so we need to keep that structure in place.

Forking the repo would require a constant synchronization of code, which just seem unnecessary.

PhysSong commented 5 years ago

Related: #4929

rubiefawn commented 5 years ago

This is purely cosmetic but having different colors for the branding appear on different kinds of builds could be a neat feature.

I posted this in the discord and got some positive reception. There's been some hearsay that nightly builds would completely replace release candidates, but considering how unstable nightly builds could be, I can still see stable release candidates being viable alongside nightly "canary" builds. text1493

tresf commented 5 years ago

Agreed. @iansannar color coding is a great way to communicate quickly and effectively to users that they're on an unstable build.

We can do this programmatically with our automated build scripts by having a build type and colorizing a few key images respectively. (please adjust below as needed)

# blue splash
convert data/themes/default/splash.png -colorspace gray -fill "#0068C1" -tint 100 ~/Desktop/splash.png

# yellow splash
convert data/themes/default/splash.png -colorspace gray -fill "#EAC445" -tint 100 ~/Desktop/splash.png

orig blue yellow

... This will have to be repeated for any branded icons. It would be worth documenting them in the dedicated "coloring" issue (or here, if that's where it lives). Batch conversion can be done using mogrify. Note, some icons live in cmake/linux/icons/.

The scalable SVG can be done as well (please adjust the replacement colors, the colors I've picked aren't great, please fix them Edit: @iansannar fixed them, thanks!) format is s/#ORIGINAL/#REPLACEMENT/g

# Blue
sed 's/#27ab5f/#09a9d9/g; s/#249a56/#0267c1/g; s/#34d07b/#3479d0/g' cmake/linux/icons/scalable/apps/lmms.svg > ~/Desktop/lmms.svg

# Yellow
sed 's/#27ab5f/#fad200/g; s/#249a56/#ffa40f/g; s/#34d07b/#ffee91/g' cmake/linux/icons/scalable/apps/lmms.svg > ~/Desktop/lmms.svg

# Red
sed 's/#27ab5f/#c51306/g; s/#249a56/#780116/g; s/#34d07b/#ff7369/g' cmake/linux/icons/scalable/apps/lmms.svg > ~/Desktop/lmms.svg

lmms test test (1)

MacOS's Application/Dock/Desktop uses an .icns file which should be able to be constructed programatically as well.

Spekular commented 5 years ago

If I may bikeshed a bit, I think red might be nice for nightlies. They're "bleeding edge", and it completes the primary colors. A purple would also evoke "nightly" for me, somehow. Yellow feels offputting to me, like it would subtly discourage me from launching LMMS. Blue for RCs is a perfect fit though, IMO.

This is a good initiative either way, so thanks for bringing it up!

On Mon, Sep 2, 2019, 16:44 Tres Finocchiaro notifications@github.com wrote:

Agreed. @iansannar https://github.com/iansannar color coding is a great way to communicate quickly and effectively to users that they're on an unstable build.

We can do this programmatically with our automated build scripts by having a build type and colorizing a few key images respectively. (please adjust below as needed)

blue splash

convert data/themes/default/splash.png -colorspace gray -fill "#0068C1" -tint 100 ~/Desktop/splash.png

yellow splash

convert data/themes/default/splash.png -colorspace gray -fill "#EAC445" -tint 100 ~/Desktop/splash.png

[image: orig] https://user-images.githubusercontent.com/6345473/64121460-e2fe7600-cd6c-11e9-9046-9c600a27da48.png [image: blue] https://user-images.githubusercontent.com/6345473/64121434-d37f2d00-cd6c-11e9-8c55-bb8fa9fecfae.png [image: yellow] https://user-images.githubusercontent.com/6345473/64121498-f7427300-cd6c-11e9-8b33-55f998e2688c.png

... This will have to be repeated for any branded icons. It would be worth documenting them in the dedicated "coloring" issue (or here, if that's where it lives). Batch conversion can be done using mogrify. Note, some icons live in cmake/linux/icons/.

The scalable SVG can be done as well (please adjust the replacement colors, the one I've picked aren't great) format is s/#ORIGINAL/#REPLACEMENT/g

blue

sed 's/#27ab5f/#2789aa/g; s/#249a56/#245e99/g; s/#34d07b/#3589d0/g' cmake/linux/icons/scalable/apps/lmms.svg > ~/Desktop/lmms.svg

yellow

sed 's/#27ab5f/#aaaa27/g; s/#249a56/#999924/g; s/#34d07b/#d0d035/g' /Users/owner/lmms/cmake/linux/icons/scalable/apps/lmms.svg > ~/Desktop/test.svg

[image: lmms] https://user-images.githubusercontent.com/6345473/64121873-fcec8880-cd6d-11e9-8fbc-19471dc5dfdf.png [image: test] https://user-images.githubusercontent.com/6345473/64121841-e8a88b80-cd6d-11e9-9e63-972a22e8e45f.png [image: test (1)] https://user-images.githubusercontent.com/6345473/64121999-6a001e00-cd6e-11e9-92b8-83093cd30649.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/3347?email_source=notifications&email_token=ACEBLGUKR7SQEQVBPA2YYELQHURFFA5CNFSM4C723WEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WAF6Y#issuecomment-527172347, or mute the thread https://github.com/notifications/unsubscribe-auth/ACEBLGSYTOLAT52X3IYSBVTQHURFFANCNFSM4C723WEA .

rubiefawn commented 5 years ago

I chose yellow to allude to the build being a "canary", like how coal miners would bring one into mines to detect unbreathable air. But red for "bleeding edge" is just as valid, and I do have a red svg ready to go at home. I'll send all the svgs once I get back.

On second though, I rather like the idea of purple. I'll try that out as well.

tresf commented 5 years ago

Canary is fairly common among "nightly" software. Chrome Canary is a yellow icon. It should be off-putting, it's a nightly. And yes, this thread is about master builds, not which color we prefer. Proposing red is exactly "bikeshedding"... Arguing color when the engineering still needs to be done. Mentioning it doesn't excuse it. This topic is about nightly builds.

rubiefawn commented 5 years ago

Progress

See this branch. ~~I think it's reasonable to have the recoloring done ahead of time, and have a script select the correct image, which is what I have done here~~ (now fully automated with scripts). The red icon is default currently, signifying a test/unofficial build (release must be specified explicitly). Ignore all the Synchro stuff, I neglected to put that on its own branch. I'm still getting familiar with git.

Sample images

Release	Beta/RC	Not specified	Canary color A	Canary color B

Other thoughts

Doing a quick google search on .icns reveals the OS X tool iconutil. I have a macbook so I'll mess around with it a bit, but I am not sure how that would function in practice (are the mac builds compiled on mac, or cross-compiled?) Some documentation regarding iconutil here.

convert doesn't look very good with yellow no matter what I try. Recoloring an SVG version of things that must be PNGs and then exporting them will look a lot better.

tresf commented 5 years ago

I think it's reasonable to have the recoloring done ahead of time

With all due respect, this is a developer decision, and please no. Simplifying human efforts using devops is going to make less maintenance, more productivity.

Sample images (5)

Let's not get out of hand. 5 builds is ridiculous considering we only have one today. The original proposal is fine.

MacOS's Application/Dock/Desktop uses an .icns file which should be able to be constructed programatically as well.

Doing a quick google search on .icns reveals the OS X tool iconutil

Right, again this thread is about master builds being continuous. A step in that direction is to run a script to convert the lmms.svg file (as well as the project file icon) to .icns for the Mac build system. Note that our SVG may first need to be simplified (technically, not from a design perspective) and converted for web consumption (Inkscape can do this) as most SVG renders don't properly draw the SVG we have today.

I already do the SVG->PNG-ICNS for another project. Here's the pseudo-code (courtesy of @lukas-w)

echo copying and converting icon
cp $ASSET_DIR/$icon_svg $icon_svg_target_dir/linux-icon.svg
rsvg-convert -w 512 -h 512 -o icon_512x512.png $ASSET_DIR/$icon_svg
rsvg-convert -w 256 -h 256 -o icon_256x256.png $ASSET_DIR/$icon_svg
rsvg-convert -w 128 -h 128 -o icon_128x128.png $ASSET_DIR/$icon_svg
rsvg-convert -w 96 -h 96 -o icon_96x96.png $ASSET_DIR/$icon_svg
rsvg-convert -w 64 -h 64 -o icon_64x64.png $ASSET_DIR/$icon_svg
rsvg-convert -w 48 -h 48 -o icon_48x48.png $ASSET_DIR/$icon_svg
rsvg-convert -w 32 -h 32 -o icon_32x32.png $ASSET_DIR/$icon_svg
rsvg-convert -w 24 -h 24 -o icon_24x24.png $ASSET_DIR/$icon_svg
rsvg-convert -w 16 -h 16 -o icon_16x16.png $ASSET_DIR/$icon_svg
convert icon_256x256.png icon_128x128.png icon_96x96.png icon_64x64.png icon_48x48.png icon_32x32.png icon_24x24.png icon_16x16.png $icon_svg_target_dir/windows-icon.ico
mkdir $project_filename.iconset
cp icon_512x512.png icon_256x256.png icon_128x128.png icon_48x48.png icon_32x32.png icon_16x16.png $project_filename.iconset
cp icon_32x32.png $project_filename.iconset/icon_16x16@2x.png
cp icon_64x64.png $project_filename.iconset/icon_32x32@2x.png
cp icon_256x256.png $project_filename.iconset/icon_128x128@2x.png
cp icon_512x512.png $project_filename.iconset/icon_256x256@2x.png
iconutil --convert icns "$project_filename.iconset" --output "$icon_svg_target_dir/apple-icon.icns"
rm -R $project_filename.iconset

tresf commented 5 years ago

@iansannar if your concern about scripting the splash screen is the colors (and only the colors) I would strongly propose that we don't modify the splash at all. If it's important from a branding perspective that the splash is also colorized, we can choose colors specifically to be those that work best with the convert command.

are the mac builds compiled on mac, or cross-compiled

On a Mac (fortunately our CI's provide this environment). There's a project out there to allow cross-compilation, but I've yet to see a project leverage it, and I can only imagine many proprietary tools are going to be missing. For the foreseeable future, MacOS can be assumed.

rubiefawn commented 5 years ago

Simplifying human efforts using devops is going to make less maintenance, more productivity.

Fair.

5 builds is ridiculous considering we only have one today.

These are just color options. I'm not proposing five separate builds. One or none of the options can be used.

I already do the SVG->PNG-ICNS for another project. Here's the pseudo-code (courtesy of lukas-w)

On a Mac (fortunately our CI's provide this environment).

Perfect! Mac was the only platform I was really worried about automating.

if your concern about scripting the splash screen is the colors (and only the colors) I would strongly propose that we don't modify the splash at all.

Then let's not for now. Less to worry about considering this is about currently unimplemented nightly builds. I was getting a bit ahead of myself.

rubiefawn commented 5 years ago

Here's the progress so far. It is now done fully by scripts. I have tested all three and they work as intended. The only thing I am not sure of is where to call these scripts from.

tresf commented 5 years ago

@iansannar after discussing on Discord, I think we've chosen yellow as the new icon color, to be set to the green color programmatically for stable builds only. Please open a PR for this at your convenience and we can start the rebranded-master-icon effort now. It's not dependant on the continuous build system, so it can be merged as soon as it's ready.

@Umcaruje @lukas-w @PhysSong @RebeccaDeField FYI.

rubiefawn commented 5 years ago

All discussion regarding the dynamic coloring will be moved to #5166.