-
-
Notifications
You must be signed in to change notification settings - Fork 462
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
update pulls from master based on version in code #40
Comments
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 Comments? |
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. |
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. |
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. |
@GaryJones @jazzsequence @tommcfarlin @grappler comments? |
I think that the updater should look for specific tags from which to pull. Let's say for example that I'm working in The Updater would basically be showing a false positive (though you could argue that I just wait until the end to tag my 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. |
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. If you used something like this then the developer can decide which way he wants. |
@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. |
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 |
@scarstens I can always read in But if we look to updating only with a new tagged release - why? Is there an advantage to a |
@scarstens You should not have So really you should choose GitHub or WordPress.org. @afragen This keeps it simple. |
@grappler your telling me I can't develop my WP.org plugins on Github. I disagree. Putting the
@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 |
@grappler isn't it simpler to assume any released tag is stable? If yes then do we even need to have a |
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. |
@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. |
@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 |
@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
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. |
I didn't know that! Thats awesome. They have been "syncing" to github for a long time now though here: |
Lets leave this thread alone now though, feel free to chat me here: |
I like the discussion. |
What do you think of replacing If If Then we would essentially demote Thoughts? @GaryJones what do you think? |
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. |
@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...) |
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. |
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 While I understand the Well? Seth, I think doing it this way there's no issue with the rollback feature. |
+1. If GitHub Branch is set, use that. If not, pull the latest tag. If no tags, pull from |
+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. |
This will also provide a level of backwards compatibility for existing plugins.
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. |
Pardon my ignorance, but do many people use |
@tommcfarlin I think it's not so much using something like |
Oh, gotcha. My mistake! Understood :). |
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
|
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" |
I tested all scenarios. Only quirky thing was a tag download showing if using I'll leave this issue open for a while in case anyone finds problems. |
@scarstens you should look at https://github.com/thomasgriffin/TGM-Plugin-Activation |
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. |
If updating from |
Yes, it works for private GitHub repos. Just need to use the |
I've actually never tested the rollback feature against |
@afragen oh, I see. But what if the repo is private and under an organization? |
It should work with |
@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. ;) |
@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. |
@raulillana can you give me access to the theme so I can take a look? |
@afragen you got it. I will push an update soon. |
It's solved guys. Token mistake. Sorry... ^^' |
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.
The text was updated successfully, but these errors were encountered: