update pulls from master based on version in code

[scarstens]

Problem is that most WP developers are used to developing "staging" code in the master branch. Why? Because thats how WP has us do it in the WP.org SVN repo. You do not want the "default" update code to ever pull from the master branch. Bad practice.

[afragen]

If we operate more like WP.org the we would only pull from tags? I do like the flexibility of not needing to tag but I understand.

I could add a new header GitHub Development Branch and if master then only pull from tag.

Comments?

[scarstens]

IMO, end users should NEVER naturally update to the "master" branch. The master branch, even for you, is being used to merge branches. After merging you still have testing to do, and merging should involve a version update. I would never want the general public to see an "update" when this happens.

I think its most important that you separate whats good for developers and whats good for general users.

Your comment "I like the flexibility of not needing to tag" generally scares me. Tagging is essential to software development process, agile development and the burndown to releases. If you want to enable these "out of ordinary" things for your own development process, I'd suggest you do it in a custom way, not the default. (custom way might be another meta tag in plugins/themes that defines pulling from branch meta)

For "standards" look at the other github plugins and see how many of them use a "dev" branch... I've found none thus far, most likely because we develop for WP.org SVN standards, which is to place "beta" code in the "master" branch and ONLY tagged releases create updates.

[scarstens]

In summary: Its arguable to the semantic ways development should happen in GIT, but functionally I think its very unsafe to assume that any untagged code is safe to pull. Why? Because its not static. Tagged code is static, which is why I firmly believe that updates should only be pushed out when tags are released on Github.

[afragen]

Good argument. I'm hoping we can have some other workflow input. I'm not opposed to this and it does follow more closely how WP.org works.

[afragen]

@GaryJones @jazzsequence @tommcfarlin @grappler comments?

[tommcfarlin]

I think that the updater should look for specific tags from which to pull.

Let's say for example that I'm working in master and I happen to push up a style.css with a version number increase, but I've not officially set a tag yet.

The Updater would basically be showing a false positive (though you could argue that I just wait until the end to tag my master branch).

But forcing users to use tags forces them to tag their releases which, in my opinion, is a good practice.

I can't speak for everyone, but this is the only way I do releases (and I use semantic versioning) so I usually know what's up from release to release.

[grappler]

I would always use tags.as I find it important and usefull. My code in master should be stable. Any development should be done in the develop branch.

What w.org offers is that you can define the stable tag in the plugin header.
Stable tag: 1.0.0 or Stable tag: trunk So in this case trunk = master

If you used something like this then the developer can decide which way he wants.

[scarstens]

@grappler Love it, your exactly correct, we should use the "Stable Tag" meta to determine how the "update" function works.

This trunk = master doesn't work for WP.org plugins that are also in Github. For example, some of my plugins I have on the WP.org SVN repo, but I build them on Github and then Tag them using Git2SVN so that the WP.org picks up my changes and so does Github. Its the nature of building with Git but being required to use SVN to be on the WP.org repo. If I put "Stable Tag: master" it would break my WP.org version of the plugin. And using trunk would break my Github version. Lets be honest, most people find our plugins because they are in the WP.org repo, I'd hate to remove them.

[afragen]

Additional primary question. Do we change to only allow updates based upon updated tags?

Currently I'm checking newest tag and version number from designated branch, or master if not defined, and then figuring out which is greater.

[afragen]

@scarstens I can always read in GutHub Stable Tag or just read in Stable Tag if it exists and make it so trunk == master

But if we look to updating only with a new tagged release - why? Is there an advantage to a Stable Tag header? Aren't we assuming any tagged release is stable?

[grappler]

@scarstens You should not have GitHub Plugin URI: in the plugin header in plugins that you have on the WordPress repo as you could update plugins without the code being hosted on WordPress.org.

So really you should choose GitHub or WordPress.org.

@afragen
GitHub Stable Tag: master check only version from master branch
GitHub Stable Tag: 1.0.0 check only tag 1.0.0

This keeps it simple.

[scarstens]

@grappler your telling me I can't develop my WP.org plugins on Github. I disagree. Putting the GitHub Plugin URI: into my WordPress plugin would not break my plugin on the repo, and IF the Github updater was installed, it would start pulling updates from Github, which is exactly what I want. Lots of WP.org developers moved there plugins to github, as its easier to handle "issues" on Github then WordPress forums.

Download Monitor:
https://github.com/mikejolley/download-monitor
http://wordpress.org/plugins/download-monitor/

@afragen is saying that he considers the version number in master as a tag so if 2.0 is tagged in Github, and 2.1 is in master, the plugin currently assumes 2.1 is the newest tag and pulls from master.

@grappler proposes requiring the stable tag, I'd also vote again creating a new meta field and just using the existing Stable Tag: field already present.

[afragen]

@grappler isn't it simpler to assume any released tag is stable? If yes then do we even need to have a GitHub Stable Tag header?

[scarstens]

Do either of you develop WP.org plugins? The forum system is horrible. You may feel that way if your not trying to manage WP.org plugins. There is not reason why I can't use both, plenty of people do it. Regardless, build it however you want, I'll fork it when your done to work for WordPress.org authors.

[grappler]

@scarstens No, what I meant what is explain well in this commet #34 (comment)

http://profiles.wordpress.org/grapplerulrich/

@afragen Yes, that is what I do. I would prefer the tags to be the deciding factor and not the version in the code.

[afragen]

@scarstens wouldn't it meet your workflow to have GHU only update from tags?

I'm leaning in that direction as the repo only really updates from tags. We would then ignore the branch version number and really just ignore branch.

If this works best I may just add a GitHub Development Branch header that if present will pull from version number of that branch. This way we can still allow for pushing dev branch only if defined.

[scarstens]

@afragen yes pulling from tags only would solve my workflow for stable updates Allowing pulling from "branch" to suck in beta code for testing would also solve DEV side of things. Setting this branch to DEV would pull dev code and MASTER would pull staging code. Allows for the full web SDLC. Thanks for clarifying that.

@grappler comment was a great read! hadn't seen that one yet. Particularly notice further down the page

Otto42 commented 17 days ago
@GaryJones You know that the git client can talk to SVN servers too, right?

This is what I'm doing and proposing, which is to allow using both WP.org and Github, since through Git you can deploy code to both. @grappler I'll have to check out your plugins, could have used fluidvids on my homepage instead of building my own.

[grappler]

@scarstens Have you seen this? http://wptavern.com/official-git-mirror-now-available-for-wordpress-core-development-repository

[scarstens]

I didn't know that! Thats awesome. They have been "syncing" to github for a long time now though here:
https://github.com/WordPress/WordPress

[scarstens]

Lets leave this thread alone now though, feel free to chat me here:
https://twitter.com/sethcarstens

[afragen]

I like the discussion.

[afragen]

What do you think of replacing GitHub Branch with Stable Tag. In order to make it work similarly to WP.org would we need to require Stabile Tag. More likely just use it if it exists.

If Stabile Tag exists then use it and update to either the listed tag or from the listed branch.

If Stabile Tag does not exist then update from newest tag.

Then we would essentially demote GitHub Branch to non needed status. I'm actually not sure anyone besides me has ever used anything other than master here anyway.

Thoughts?

@GaryJones what do you think?

[scarstens]

My only thought is that you won't be able to pull dev branch anymore without the branch meta. Maybe your fine with that, not sure why you would remove it if you already have it built. Surely it enables you to more easily pull and test plugins and theme.

[jazzsequence]

@scarstens Stable Tag doesn't necessarily need to be a "tag". On WordPress.org Stable Tag can be a branch. Or it can be trunk. Don't see any reason why the same couldn't be true here. (of course, I'm probably reading this out of context since I haven't followed the whole conversation...)

[scarstens]

Nah, your probably right, I'm probably over-complicating it. Branch info in the stable tag should be flexible enough. @afragen just want to make sure we find a way / account for a way to "include branches" in the rollback feature we just built.

[afragen]

Part of the difficulty is that there are many people using this for their updating and I don't wish to dramatically change the way it works.

I'm thinking now that the simplest change would be to pull the newest tag. If there are no tags then it would pull from master. If GitHub Branch is set to something other than master then it would pull from that branch. If GitHub Branch is not present then it would again default back to tags or master if there are no tags.

While I understand the Stable Tag I don't necessarily think it's needed here.

Well?

Seth, I think doing it this way there's no issue with the rollback feature.

[GaryJones]

I'm thinking now that the simplest change would be to pull the newest tag. If there are no tags then it would pull from master. If GitHub Branch is set to something other than master then it would pull from that branch. If GitHub Branch is not present then it would again default back to tags or master if there are no tags.

+1.

If GitHub Branch is set, use that. If not, pull the latest tag. If no tags, pull from master. If there is no branch called master, pull from the default branch (we already do a check to find out what that is).

[tommcfarlin]

+1 to this, as well.

This order of operations (for lack of a better term) is great as I think it has the greatest level of fault tolerance, and promotes the best practices for developers tagging and managing their repositories.

[GaryJones]

This will also provide a level of backwards compatibility for existing plugins.

1. If I've not used the GitHub Branch header, then the previous lookup was to master. If a tag now exists, it gets used, and if it doesn't, then master is used. All good.
2. If I have used the GitHub Branch header, then it carries on as expected. The main use case was when the default branch on the repo was develop, or something other than master (as per git-flow approach), so pulls were expected to come from master, or something custom.

The Branch header needs to stay for compatibility (and please don't introduce Stable Tag), but the recommendation should be that it is not used, favouring tagging releases instead.

[tommcfarlin]

Pardon my ignorance, but do many people use stable as a tag on GitHub? In most of the projects that I watch, I normally see master, develop (or something similar), and then just tagged versions which are assumed to be stable.

[afragen]

@tommcfarlin I think it's not so much using something like GitHub a Branch: stable as it is using something like Stable Tag: 1.2.0 as lis required on the WP.org repo.

[tommcfarlin]

Oh, gotcha. My mistake! Understood :).

[afragen]

Just pushed and tagged 2.4.0. It has the new updating methodology. Hopefully I explained it well enough in the README to avoid confusion. If it's not working as expected let me know.

Recap

1. Tags used if present.
2. If no tags or branch other than GitHub Branch: master then updates come from branch.

[scarstens]

i didn't test branch, but I tested everything else in single site, works great, modified Whitelabel Framework to disable its internal updater if this plugin class is present, will be removing mine once I figure out how to "require plugins". I think this is "hashtag-done"

[afragen]

I tested all scenarios. Only quirky thing was a tag download showing if using develop branch and local_version > remote_version. But that doesn't really matter as no update is happening.

I'll leave this issue open for a while in case anyone finds problems.

[afragen]

@scarstens you should look at https://github.com/thomasgriffin/TGM-Plugin-Activation

[raulillana]

Hi @afragen is this implemented in last tag or either in -develop?

Also, is this working with GitHub private repos? I just can't get it to update tagged versions...

Thanks.

[afragen]

If updating from GitHub Branch: develop it won't update from tags, only from version number change in branch.

[afragen]

Yes, it works for private GitHub repos. Just need to use the GitHub Access Token header

[afragen]

I've actually never tested the rollback feature against develop

[raulillana]

@afragen oh, I see. But what if the repo is private and under an organization?

[afragen]

It should work with GitHub Access Token header. Don't know about organizations I'm not in any to test.

[raulillana]

@afragen i guess, if my user account has access to a private repo (whether or not in an organization) and a personal token is created for my user account to access public and private repos, it should access the private repos in my organizations too, right?

BTW the plugin is showing only branches instead of tagged versions as you can see in the pic i attached before.

Tell me if you want access to my organization to test it out and give me a hand, and thanks for the support. ;)

[grappler]

@raulillana It should work. I do not not see any reason why. I was the one who tested the private repo and it was a simple copy and paste. You should be able to do the same. If you don't get an update within 24 hours then something might be broken.

[afragen]

@raulillana can you give me access to the theme so I can take a look?

[raulillana]

@afragen you got it. I will push an update soon.

https://github.com/ABInternet/abn

[raulillana]

It's solved guys. Token mistake. Sorry... ^^'