Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Allow continuous use of master version #3347

Closed
jasp00 opened this issue Feb 13, 2017 · 26 comments
Closed

Allow continuous use of master version #3347

jasp00 opened this issue Feb 13, 2017 · 26 comments
Labels
enhancement meta

Comments

@jasp00
Copy link
Member

jasp00 commented Feb 13, 2017

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
Copy link
Member

tresf commented Feb 13, 2017

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
Copy link
Member Author

jasp00 commented Feb 15, 2017

Then let us wait until there is more demand.

@DeRobyJ
Copy link
Contributor

DeRobyJ commented Mar 19, 2017

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
Copy link
Member

tresf commented Mar 20, 2017 •
edited
Loading

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
Copy link
Member Author

jasp00 commented Mar 20, 2017

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
Copy link
Member

tresf commented Mar 20, 2017

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
Copy link
Member Author

jasp00 commented Mar 20, 2017

My first thoughts are Travis-CI.

Mine too.

@DeRobyJ
Copy link
Contributor

DeRobyJ commented Mar 21, 2017 •
edited
Loading

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
Copy link
Member

tresf commented Mar 21, 2017 •
edited
Loading

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: v1.2.0-rc2...master

@DeRobyJ
Copy link
Contributor

DeRobyJ commented Mar 21, 2017

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
Copy link
Member

tresf commented Mar 21, 2017

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
Copy link
Member

PhysSong commented Aug 2, 2019

Related: #4929

@rubiefawn
Copy link
Contributor

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
Copy link
Member

tresf commented Sep 2, 2019 •
edited
Loading

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
Copy link
Member

Spekular commented Sep 2, 2019 via email

@rubiefawn
Copy link
Contributor

rubiefawn commented Sep 2, 2019 via email •
edited
Loading

@tresf
Copy link
Member

tresf commented Sep 2, 2019

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
Copy link
Contributor

rubiefawn commented Sep 2, 2019 •
edited
Loading

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
logo-green-round logo-beta-round logo-red-round logo-canary-round logo-nightly-round

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.

@JohannesLorenz JohannesLorenz mentioned this issue Sep 3, 2019
Open
11 tasks
@tresf
Copy link
Member

tresf commented Sep 3, 2019 •
edited
Loading

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
Copy link
Member

tresf commented Sep 3, 2019

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

tresf commented Sep 4, 2019 •
edited
Loading

@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
Copy link
Contributor

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

@rubiefawn rubiefawn mentioned this issue Sep 10, 2019
Draft
9 tasks
@PhysSong PhysSong mentioned this issue Apr 20, 2020
Closed
@DomClark
Copy link
Member

Nightlies implemented via #6476 and LMMS/lmms.io#351. Granular project upgrades implemented in #5660.

@Loopshape

This comment was marked as off-topic.

Sign in to view
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement meta
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@Loopshape @DomClark @tresf @jasp00 @DeRobyJ @rubiefawn @Spekular @PhysSong