+1, now we don’t have stable release channel – all changes are live on production. @emrevona if You use TortoiseSVN just click RMB on trunk folder and chose “Branch/tag” option. Then You need put revision to tag and confirm it 🙂 And the most important: in readme.txt You need to change “Stable tag” from trunk to some version that You taged.
After you have made the a commit which releases a new version, you just copy the whole of trunk to tags with the appropriate release version.
See, for example:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/tags/release-1.0 \
-m “Tagging the 1.0 release of the ‘calc’ project.”
As beherit says, you also need to update the readme.txt tag which wordpress.org uses.
Then I can work out the current release version and the commit that caused simply from subversion. I normally install plugins using svn, so this makes it very easy for me to update. As a side effect, it also makes you version history a little better.
Actually I don’t release new version after little changes.
https://wordpress.org/plugins/wp-fastest-cache/stats/
I released the previous new version at 12th July. After 12th July I have implemented new features. And I released the latest version at 29th August. During 47 days I was waiting for any issue. and I released new version when I am sure that there is no problem.
Isn’t it a good way?
You are wrong. For example: after release version 0.8.6.0 You have done a lot of commits, when someone clicked to download version 0.8.6.0 really download trunk folder with latest commits. Now we have version 0.8.6.1 and if You for mistake commit a very big bug that broken site then this bug will have a lots of users e.g. those who just update from version 0.8.6.0 or those who just download Your plugin.
I am running of trunk at the moment, which isn’t ideal, no. As Beherit says, so are many other people.
A more normal workflow would be this….
On trunk:
commit, commit, commit,
decide that you have reached a release
commit last documentation update for release (including stable tag update)
copy trunk to tags with the new release version
start commits for new version.
If you want to wait for issues before release, then yes you can do this — you can make the svn copy from the last commit you want to be in the release, even if it is not the most recent commit on trunk.
For my own usage, I would rather use this plugin from a stable release rather than directly from trunk.
I prefer agile development. What do you think about it?
@emrevona You can use agile development or what You want – the problem is that You not tag version that You release and user don’t download specific version but the latest version from trunk (with latest commits, not tested, unstable etc).
@emrevona Still there is no tags and we have beta-unstable function in trunk which You are tagged as stable tag 🙁
noo. Now it is stable version. I changed the files many times ago.
I think You don’t understand how WordPress SVN works 🙂 In readme.txt You should add tag number in “Stable tag” – this is stable tag for Your plugin version, not WordPress version as You already set. For now You should change “Stable tag: 4.7” to “Stable tag: 0.8.6.3” and then tag latest revision in trunk folder as “0.8.6.3”. For now download button points to latest files from trunk folder.
you are %100 right 🙂 I don’t know how to use. If you teach me, I will be so happy.
@emrevona which software are You use? Which OS? 🙂 If You tell me I will send to You a small FAQ 😉
please help me via email 🙂 fastestcache@gmail.com
