[wp-meta] [Making WordPress.org] #5652: Plugin Readme Header Spec Update

[Making WordPress.org]

#5652: Plugin Readme Header Spec Update
--------------------------------------+---------------------
 Reporter:  pewgeuges                 |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:
Component:  Plugin Directory          |  Resolution:
 Keywords:  has-patch needs-approval  |
--------------------------------------+---------------------

Comment (by pewgeuges):

 @dd32,

 You don’t seem to have got the point either, in spite of the details
 posted above. Look:

 Replying to [comment:9 dd32]:
 > I don't personally see the need for adding extra headers here to be used
 as validation that the value is right.

 Only you are inventing the concept of validating that the value is right.
 In the examples above, the use case of every field having a different
 version number may also occur:

 {{{
 Package Version: 1.2.4d0
 Tagged Version: 1.2.3
 Stable Tag: 1.2.0
 }}}

 Let’s say that 2 days after the last minor version release, a new bug
 occurring when plugin XYZ is used alongside was quickly fixed in v1.2.1
 and made available to the reporter as well as to the Community monitoring
 the Support Forum. Same for v1.2.2 and 1.2.3. Then, an experimental
 feature is made available in trunk/ as v1.2.4d0. Later on, it might make
 it into v1.3.0:

 {{{
 Package Version: 1.3.0
 Tagged Version: 1.3.0
 Stable Tag: 1.3.0
 }}}

 Note that this is a particular situation occurring at release time.

 > The way I'm reading this is:
 > {{{
 > Stable Tag: 1.2.3
 > No, What's your "stable tag"?: 1.2.3
 > Are you sure? What's your actual version you want released?: 1.2.3
 > }}}

 Sorry for not providing the example before. I didn’t suspect that
 “changing the ‘Stable Tag’ field to the development version (2.5.9d1)”
 would not help you understand that this accident would have been prevented
 if we had a Package Version field so the Stable Tag wouldn’t be mistaken
 and used for the package version by lack of anything close to a version
 number as you will find in whatever state-of-the-art readme header.

 {{{
 Package Version: 2.5.9d1
 Stable Tag: 2.5.8
 CAUTION: THE S. T. FIELD IS PARSED FOR RELEASE CONFIGURATION.
 }}}

 > There's also some misunderstandings around how WordPress.org plugin
 versions are handled, WordPress.org is not a perfect system, infact, it's
 actually very bad, you really only have 1 version that is the current one
 for download and that's it, you have the ability to tag older releases,
 have a development version in trunk, etc, but it's not really used at all
 the way many would do so elsewhere.

 We have the ability to download every single tag plus trunk/ under the
 Advanced tab. What you are telling doesn’t make sense to me and I wonder
 about the alleged misunderstanding. Why should the blog engine offer older
 versions in the plugin catalogue? I think it’s enough to be able to
 download the *.zip and upload it to the blog for installation whenever an
 older version is desired.

 > WordPress.orgs plugin system is intentional in that, it's migrated away
 from being a central platform for developing plugins, to a "upload your
 latest plugin release" and that's it.

 That’s very bad news. WordPress already advises to delete older versions,
 which is bad. It works very well for developing plugins without an
 excessively atomic commit history. Normally, development versions are
 committed only either to share on the Forum or for pre-release testing, or
 eventually for traceability to avoid too mixed-up changesets.

 > I don't think anyone is going to say "The implementation of the Stable
 Tag header is perfect", but I don't think this solution is actually a
 solution that's worth investing in.

 You don’t need to invest a single cent. Instead, you’re expected to add
 the Package Version field and the CAUTION warning, plus the optional
 Tagged Version field. That’s all. As of the fill-in-the-blanks
 instructions, you may ditch them if you can’t see the point, and if you
 want the PRT to keep being bothered with reviewing mislabeled plugins.

 > Instead, I personally think we're better off with the direction of
 removing the reliance upon the field entirely, dropping support for it
 effectively, through something like #5484.

 You should maintain the stable tag, or we won’t be able to have tagged
 versions without releasing every single one in the wake. See above.

 In comparison, #5484 seems like a rather bad “good idea”. You need to
 commit to trunk/ anyway. Why not do the release “in one go” as designed in
 [https://developer.wordpress.org/plugins/wordpress-org/how-to-use-
 subversion/#create-tags-from-trunk Using Subversion].

 > This ticket should closed as `wontfix` IMHO, but I'm not going to mark
 it as such to allow discussion from anyone else without it being re-opened
 again. I'll close it if it's still open in a few months time instead.

 You primarily need to upload the new attachment (license corrected to
 GPLv2) to https://wordpress.org/plugins/readme.txt

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