Apply Patch SUPEE-8788 and create branch for 1.9.3.* about magento-lts HOT 9 CLOSED

We should probably make it clear in the README that patches are only being applied to the latest version.. E.g. it is not safe for someone to use the 1.8.1 branch as it does not contain every patch.

from magento-lts.

But isn't it Magento's practice to release a new SUPEE patch AND a new version?

Example 8788:

• latest: 1.9.2.4
• Magento releases SUPEE 8788 AND 1.9.3.0 with 8788 included.

So do yo actually mean: patches only for the second-latest version? The 1.9.2.4 branch? No patches for 1.9.2.3 and lower?
How can this be communicated?

from magento-lts.

Hi @colinmollenhour @infabo I'll apply the patch to all 1.9 and 1.8 versions today. I've been waiting because there have been so many issues with the patch until now (I think they're on version 3 of the patch now). At the top of the readme there is a table that lists applied patches, I'll also update those.

If either of you have time, can you review the 1.9.3 branch I've created so I can go ahead with making that the default?

from magento-lts.

Perhaps rather than mirroring Magento's versioning as branches it would make sense to use some compromise to reduce the number of branches that need to be maintained.. I would propose for consideration keeping only the major versions in separate branches:

• 1.8
• 1.9

This way if someone is tracking those versions they always get the latest in that version and the 1.x.x.x branches can be dropped so that people don't use them assuming they are safe to use and nobody has to maintain them. Another way to put it is that magento-lts would only support the latest version in each major version and not older minor versions. If there was ever a 1.10 released we would have a new branch for it and 1.8 and 1.9 would remain and would continue to at least receive security patches.

This also solves the 1.9.2.4 plus SUPEE 8788 vs 1.9.3.0 being the same code since for magento-lts it would just be 1.9 with all latest patches.

from magento-lts.

That would definitely make my life easier, but I think we ( @LeeSaferite and I ) decided at some point we needed these fine-grained branches so that we could track every release from Magento separately to easily facilitate any version someone would want to run while still allowing patches (community or magento) to come in with composer update (otherwise, we'd have to move the tag every time).

However, that was before every version release was a patch-level release. Definitely warrants some re-consideration - though I'm not sure we can change it now that people are probably using some of those fine grained branches in their composer.json

from magento-lts.

I would drop the build-part (or whatever the 4th digit stands for) for the branches. 1.9.3.x may be the next branch. Magento's versioning for 1.x isnt semantic, so patchversion updates (1.9.2.x to 1.9.3.x) can have breaking changes (as the new Mage_Uploader for example).

from magento-lts.

Looks like a release hasn't been tagged since 1.9.1.1 and for "stable" packagist only cares about tags and not branches. So is it safe to assume that if someone is currently using magento-lts with composer they are probably using something like "~1.9.2@dev"?

I am suggesting branches be major versions only (1.8, 1.9, etc) and tags could be set each time a point release is made by Magento (e.g. tag 1.9 as 1.9.3.0 after SUPEE-8788 is applied).

Additionally we could tag the major version branches once a month or so in order to let them be used without the "@dev" stability based on the latest official Magento version. The current 1.9.2.4 branch which is actually 1.9.2.4 plus a handful of improvements could be tagged as "1.9.2.4.1" and the next one would likely be "1.9.3.0.1". It is ugly that there are so many levels in the version number but unfortunately "1.9.1" would conflict with the old tagged release "1.9.1.1". The alternative could be to use double-digit numbers like "1.9.10" and "1.9.11" so the third number always starts at 10 and just climbs until the next official Magento release (which would be a new branch 1.10 with a new release starting at 1.10.10).

Just throwing out some ideas. :)

from magento-lts.

first make sure composer is able to handle x.y.z.x.x tags.
Also I would keep the branches for minor versions, as often enough people are very defensive, on the other side it becomes a lot less common with newer versions, that people are not able to update even minor versions...

actually, how many people do even install via composer? I would expect the main tool for installs is magerun?

from magento-lts.

;P for minor upgrades .... sometimes even unzip all ... and see if it works
(check local vs core + extension testing)

On Wed, Oct 19, 2016 at 5:05 PM, Daniel Fahlke [email protected]
wrote:

first make sure composer is able to handle x.y.z.x.x tags.
Also I would keep the branches for minor versions, as often enough people
are very defensive, on the other side it becomes a lot less common with
newer versions, that people are not able to update even minor versions...

actually, how many people do even install via composer? I would expect the
main tool for installs is magerun?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#112 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAn0a1aAe8o-tOt-AwMef0mJm1_cwQwBks5q1jGhgaJpZM4KT3o9
.

from magento-lts.