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.

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

[RFC] v0.1 release #339

Closed
10 tasks done
WithoutPants opened this issue Jan 30, 2020 · 10 comments
Closed
10 tasks done

[RFC] v0.1 release #339

WithoutPants opened this issue Jan 30, 2020 · 10 comments
Assignees
Labels
help wanted Extra attention is needed
Milestone

Comments

@WithoutPants
Copy link
Collaborator

WithoutPants commented Jan 30, 2020

We've got some pretty large changes in the pipeline, and I'd like to do a formal v0.1 release before we merge those in.

Pending PRs to include

Other required tasks

  • Update travis configuration to not build the master branch
  • Merge develop into master
  • Manually tag v0.1 and create release
  • Merge master back into develop
@WithoutPants WithoutPants added the help wanted Extra attention is needed label Jan 30, 2020
@ghost
Copy link

ghost commented Jan 31, 2020

Good plan. #336 and #337 are good to merge unless there are any complaints.

@bnkai
Copy link
Collaborator

bnkai commented Jan 31, 2020

I would also add update check version functionality to the required tasks.
Currently it relies on the hardcoded version and the fact that we have single tag for stable/dev releases.
It could also be useful if we can decide on a naming scheme for the version.

#336, #337 are ok by me also
#333 testing now due to rebase looks ok
#326 i need to make a quick test for the latest commit ok too
#335 needs a little feedback . but is necessary to include ok

@WithoutPants
Copy link
Collaborator Author

It could also be useful if we can decide on a naming scheme for the version.

Based on semver naming, is there anything wrong with v0.1?

@WithoutPants
Copy link
Collaborator Author

WithoutPants commented Feb 2, 2020

Propose the following changes before we release:

  • change the current v0.0.0-alpha_dev tag to latest instead. This tag represents the latest version on develop and should be documented as such.
  • travis will tag the current commit with latest when on the develop branch. It will not automatically tag commits in the master branch. This should mean that the master branch will only be released when already tagged.
  • use git describe --tags --exclude latest to generate the STASH_VERSION environment variable - this will not be used to tag the release, see above. git describe will show the current tag if the commit has one, or the latest tag (excluding latest) with a suffix showing the number of commits since the last tag, and the commit hash. For example, running git describe --tags --exclude *_dev, gives the result v0.0.0-alpha-252-g066295f. This gives us a decent version string to deal with for the latest builds. The STASH_VERSION generation can be moved out of travis and into the makefile instead.
  • latest can be have prerelease set to true. The master builds should have it set to false.
  • In order for git describe to work correctly, the tagged release commit must exist on both master and develop branches. I think this will mean we need to fast-forward merge to master, and hotfixes to releases will need to be commit-merged to the develop branch from master. Someone with better git experience might need to help me out here. This will mean that master will need to be merged into develop after the release has been tagged.
  • change the check version code to accomodate for the above changes. If version from GetVersion returns a version string with -X-githash suffix, then we can conclude that it is a latest or development version and check against the latest tag. Otherwise, we'd be looking for the latest release that has prerelease set to false. This assumes that we don't do bug fix releases for previous releases (ie releasing 0.1.1 after 0.2.0).

@bnkai
Copy link
Collaborator

bnkai commented Feb 3, 2020

I'm fine with this. It needs to be put to test to see if it works like you mention though.
So for the dev branch we only have ONE tagged version latest while for the master we'll have multiple that don't get autogenerated.

One extra thing to check is the docker image
It currently fetches the linux binary like this
curl -L -o /stash $(curl -s https://api.github.com/repos/stashapp/stash/releases | grep -F 'stash-linux' | grep download | head -n 1 | cut -d'"' -f4)
It actually gets the dev binary.
The development-x86_64 is autogenerated on every merge.
How is the stable (latest) created? @Leopere

@WithoutPants
Copy link
Collaborator Author

As discussed on discord - we'll use latest_develop for the pre-release version.

@WithoutPants
Copy link
Collaborator Author

I've generate and curated a set of release notes for this version. It was generated from commits between v0.0.0-alpha and the current commit.

Script to generate the rough draft is here:

#!/usr/bin/env bash
previous_tag=0
for current_tag in $(git tag --sort=-creatordate)
do

if [ "$previous_tag" != 0 ];then
    tag_date=$(git log -1 --pretty=format:'%ad' --date=short ${previous_tag})
    printf "## ${previous_tag} (${tag_date})\n\n"
    #git log ${current_tag}...${previous_tag} --pretty=format:'*  %s [View](https://github.com/stashapp/stash/commit/%H)' --reverse \
    git log ${current_tag}...${previous_tag} --pretty=format:'*  %s' --reverse \
     | grep -v Merge | sed -re 's|\*  (.*) \(#([0-9]+)\)$|*  [#\2](https://github.com/stashapp/stash/pull/\2) \1|g'
    printf "\n\n"
fi
previous_tag=${current_tag}
done

Release Notes

v0.1.0 (insert release date here)

New Features

  • #203, #333 Configurable custom performer scrapers
  • #230 Support looping of short videos.
  • #230 Optionally auto-start videos.
  • #204 Add scene auto-tagging from filename
  • #255 Add Play random button to scenes and scene markers page
  • #262 Allow uploading of custom scene covers
  • #236, #285, #333 Configurable custom scene metadata scrapers
  • #265 Add "Open Random" to performer list
  • #280 Add scenes tab to performer page
  • #296 Add version check
  • #334 Add "O-" (or "splooge-") counter

Improvements

  • #218 Improve scene wall layout
  • #225 Read config from current working directory before user profile directory
  • #165 Upload pull request builds to transfer.sh
  • #230 Save interface options
  • #242 Change marker time input to mm:ss
  • #246 Allow pasting image into performer/studio
  • #232 Scene UI improvements
  • Update JWPlayer to 8.11.5
  • #252 Beautify scene list table
  • #257 Add responsive menu
  • #259 Make scene metadata from file metadata optional
  • #268 Add transcode seeking support to JWPlayer and remove video.js
  • #253 Allow exclusion patterns for scanning
  • #269 Support scraping from other stash instances
  • #300 Display both server address and listening address in log
  • #313 Add scene duration filter
  • #322 Add useful links to about page
  • #328 Generate a new order when selecting random sorting
  • #326 Maintain filter parameters in session
  • #336 Change thumbnail default size and resize algorithm
  • #337 Improve caching of static files and performer images

Bug fixes

  • #215 Fix importing on Windows
  • #231 Fix previews sometimes taking a long time to generate
  • #251 Fix input fields losing focus when switching between windows
  • #263 Fix VTT for chapter display in scene players
  • #295 Fix usage of Box.Bytes causing depreciation message

@Leopere
Copy link
Collaborator

Leopere commented Feb 5, 2020

I'm fine with this. It needs to be put to test to see if it works like you mention though.
So for the dev branch we only have ONE tagged version latest while for the master we'll have multiple that don't get autogenerated.

I can spin up some temporary repos we can test on if that helps otherwise I'm not entirely certain what this is going to look like in practice.

This is far more professional than I've had to get with anything in the past in some aspects so I'm very interested in learning how this flow works in deployment.

@Leopere Leopere added this to the Version 0.1.0 milestone Feb 5, 2020
@Leopere
Copy link
Collaborator

Leopere commented Feb 5, 2020

One more fix prior to closure needs to be reviewed #350

@WithoutPants
Copy link
Collaborator Author

Release complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants