2

Much of the time, take this field collection migration issue for example, when I find an issue with a drupal module, there has already been an issue filed, and in some cases the issue has a status of Closed (fixed). In the sidebar there is a version mentioned. It seems likely that that version is the one you set when you file the issue, specifying which branch of the code you saw the issue in.

When the issue has been Closed (fixed), does that mean that if you grab the specified version, that the code will include the patch? Is there any way of knowing when a fix has reached the stable branch?

  • Patches are always applied to the dev branch (8.x-1.x). I can't remember the rules regarding your follow-up. – Eyal Jan 21 '16 at 8:34
  • A closed issue does not mean that any patch provided on the issue queue has been applied anywhere. Also, fixes and patches are applied to any branch not only to the stable one. – TheodorosPloumis Jan 27 '16 at 8:40
  • I would have assumed that closed (fixed) means that if there was a successful patch in the thread that it has been applied to the branch. – UltraBob Jan 27 '16 at 8:42
2

As mentionned by Eyal a patch is always applied to the -dev version of the module. That's already a good stuff to know. So yes, if a patch is committed you can download the -dev version specified in the issue (or apply the patch separately if needed).

Usually the patches included in a new release are listed in the changelog: ![enter image description here.

note: normally once a patch is committed the issue status becomes "closed (fixed)" and you will ind this kind of details in the latest issue comments: enter image description here

In the sidebar of the presentation page of the module the "View pending patches" can be helpful to check if the issue you are looking for is still opened or fixed. There is also the "Views commits" link for a quick overview. this page provides a detailed list of the patches implemented (issue date, version , description, id).

--

The official doc https://www.drupal.org/issue-queue/status could also help you to understand the process.

  • Thanks this is useful, do I need to ask a seperate question to find out about how to tell when a fix goes into the stable branch? – UltraBob Jan 23 '16 at 1:55
  • you can enable the "update manager" module on your drupal website to be notified of new release (stable or dev). From there you can access the changelog and see if the patch you are looking for has been added. A patch committed to the dev is generally added in the next release. If not there is probably an explanation on the issue comments. It is also good to know that for every issue you can clik the "follow" button (below the summary block on the right sidebar). You will find the list of followed issues in your dashboard on drupal.org. This is one way..there are others (with git for eg). – xaa Jan 23 '16 at 11:28
  • The thing is, when I find an issue that has been closed (fixed) I would like to know the status. Is it still just in dev or has isn't made it to stable already. – UltraBob Jan 23 '16 at 12:06
  • by reading the changelog. You can also compare the date of the release and the patch. The version number of a module helps you too. ex the patches of fieldcollection 7.x-1.0-beta9 have probably been included in the 7.x-1.0-beta10. Maybe this out of the scope but It worth to mention that GIT is your friend for this kind of questions. – xaa Jan 23 '16 at 15:56
1

Patches are not always applied to the dev branch. This is not the case always although it would be. For example there may be 2.x and 1.x version or maybe the stable release is 1 year ahead from the dev branch etc.

The official rules for submitting patches can be found here: Submitting patches.

In reality the patches refer to the version (release or branch) that issued the patch. See the example. And the naming rules say that you should add the project branch in the patch name too!

When you create an issue on D.O. you are obligated to enter the project version that issued the issue. So any patches submitted there refer to the "version of the issue". When the branch is the dev branch which changes often the patch need to change often too! That's why you see so many patches for an issue if it is not closed soon.

Also, D.O. has a special bot that takes patches from issues and apply them to the project so every patch has a pass status. See more at Drupal.org Testbots.

A typical patch for a project issue

D.O. : Drupal.org

  • I'm not sure I entirely follow. If I filed a bug against the stable branch, how would patching go? – UltraBob Jan 27 '16 at 6:49
  • 1
    If the issue refers to a stable branch (let's say 7.x-1.0) the patch should refer to that branch too (7.x-1.0). Saying that someone should apply the patch only for the current stable release (7.x-1.0) and testing etc will happen for this release (7.x-1.0). In practice someone downloads (or clones from git) the 7.x-1.0 version of the module and then applies the patch. The same to create the patch. – TheodorosPloumis Jan 27 '16 at 8:37
  • So does that mean a fix is more likely to be released on the stable branch quickly if it was reported against the stable branch? Or is the process generally to merge the dev branch back into stable before making the next stable release? – UltraBob Jan 27 '16 at 8:40
  • 1
    It depends to the workflow of each module and the development process each module maintainer follows. It would be nice to have fix-dev->dev->stable but this does not happen always. The most critical point for patches is to work properly (have (simplytest) tests to verify that and have too many users also to verify that the patch is working normally) so maintainers can use them on the future releases. – TheodorosPloumis Jan 27 '16 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.