search

mzajkowski / umbraco-backoffice-themes

Additional themes for Umbraco backoffice.
MIT License
7 stars 3 forks source link

Integrate AppVeyor build for NuGet / Umbraco Package #9

Open Weegy opened 6 years ago

Weegy commented 6 years ago

Kudos to @leekelleher (Boilerplate is from stacked-content)

Weegy commented 6 years ago

It includes also a Dashboard transformation for the "settings section". Test NuGet can be found here https://www.myget.org/feed/byte5digital/package/nuget/Our.Umbraco.BackofficeThemes

Weegy commented 6 years ago

@leekelleher Thanks for your time, I'm glad I didn't mess it up :)

mzajkowski commented 6 years ago

@Weegy please pull the latest changes from the other PR before applying any fixes :) Can't wait to see them applied and merged. We're getting there!

I'm more than happy to use this Community feed to serve the package.

@leekelleher can you advise on versioning strategy? How you're dealing with releases of alphas/betas etc?

Weegy commented 6 years ago

Merge Succesful, I will implement the other fixes ASAP

leekelleher commented 6 years ago

@mzajkowski - re: Versioning. Depends how much maintenance and discipline you want to have for the project.

Most of the UMCO projects have a branching workflow. master is only for stable/released code, (this could also be for beta releases). We have a develop branch, which is configured as our default branch, so all forks/PRs will target that by default. This means that we can separate our future dev work from releases. Then we use (internal) PRs to merge develop into master when we're ready for a new release. I can't remember if this is called GitFlow or GitHubFlow - or something else?

With version numbers, we try to stick with SemVer... Bump major for breaking-changes, bump minor for new features and bump patch for bug fixes.

On a few of our projects, I stuck with using v0.x for a while (see Ditto, NC and DTGE), because there's a clause in SemVer that says as v0.x is a pre-release and you can make any many breaking-changes as you please. Suggesting that it should never be used in production, but I think I held on to that idea for too long ... so I wouldn't recommend doing v0.x anymore.

mzajkowski commented 6 years ago

Thanks @leekelleher for your feedback.

This is similar to what we're following in most of our projects too. I was always curious about -alpha and -beta releases, but it seems like it's just a visual name for a specific release rather than strategy or something like it.

I'll try to find some time to combine it all into a small and clear CONTRIBUTING.md file with all the details about desired strategy here - maybe it'll be useful for someone else trying to work on it for the next project.

In terms of 0.x.x - I'm with you. It's nothing good to see product which is pretty stable at the market still being in 0.1.29 or something :) Let's aim to release 1.0.0 here first.

Cheers and can't wait to see @Weegy's changes applied :) Thanks for your time and hard work so far.

leekelleher commented 6 years ago

I forgot to add. With the develop branch and AppVeyor CI builds. All commits in develop are built and pushed to the MyGet feed, and all suffixed with -alpha. So we don't usually add "alpha" manually to our version numbers.