[wp-meta] [Making WordPress.org] #5645: Feature Request: Update on reversion to `trunk/`

[Making WordPress.org]

#5645: Feature Request: Update on reversion to `trunk/`
------------------------------+---------------------
 Reporter:  rumperuu          |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+---------------------

Comment (by pewgeuges):

 @dd32, @Ipstenu,

 > Another thing worth noting, is that since Github is your primary
 development platform, syncing every commit to plugins.svn might not be
 needed, and partially lead to this situation. Personally I use the 10up
 Github action which deploys any releases I tag on Github to be pushed over
 to plugins.svn instead.

 And:

 > Word of warning: If you sync every commit from Git to SVN, you'll
 eventually get a stern email from the plugins team asking you to stop,
 because (in the past) we used to regenerate all your zips when you did
 that. Now we only rezip the one branch you're on (say, Trunk) but still,
 there's no reason to do that.

 The reason why trunk/ has been updated is the transition to a WordPress
 Coding Standards conformant code base, that @rumperuu has worked out. In
 order for SVN to be able to keep generating meaningful diffs, we needed a
 first commit solely dedicated to replacing CRLF with LF, because the code
 base had been developed on Windows and needed to get its EOL normalised.
 The diffs show totally changed files, where any other changes would be
 hidden. A second commit was then dedicated to committing the standardised
 codebase as prepared on GitHub. The diffs look great and allow to exactly
 localise the WP-compliance changes. In a last go, the version number in
 trunk/ was then synced with the current release.

 And the reason why trunk/ needs to be updated more often than just for
 releases is the need to make development versions available. Support
 responses on the Forum often linked to trunk/ where the current
 development version enabled the user to help testing and to evaluate the
 fitness for use.

 Anyway, thanks for the hint about syncing version numbers in Stable Tag
 and Plugin Main. Thankfully that is what we always did, but that is only
 true at release time and inside each stable tag.

 Later on, depending on the need to make development versions available,
 trunk/ would have the version number (in Plugin Main) incremented (d
 series appended to incremented minor version), **whereas the Stable Tag
 must remain stable.**

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5645#comment:5>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org