-
Notifications
You must be signed in to change notification settings - Fork 347
Add pCP OS package to Stable branch. #1374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pCP OS package to Stable branch. #1374
Conversation
|
Need to get pCP packages for this branch too before I change the update script. I was not sure how you wanted to do a partial merge from 9.1 into this branch, so I just cherry-picked the commits, and manually did the change log. |
|
@paul-1 thanks for this PR. But that's definitely the kind of change I wouldn't want to port to stable without any good, long testing in dev first. I'd actually prefer not to port such a change to dev, as it's not a bug fix. Would this be required because the update script would not work the old way any more? |
|
That's a catch22. The new update script is not aware of branches, and that it would need to use the CPAN method to upgrade stable, or switch back to release. Until the updated packaging exists in all 3 branches, I cannot change the production update script to start using it. What part of this change in packaging makes you nervous? At the end of the day all we really did was rename Custom.pm to pCP.pm |
|
There are 9 files in this change set 😉. And it's not just files renamed. Most of them have some changes to them compared to the old files. Breaking an update mechanism can be problematic, as some non-technical people might end up with a (for them) bricked system. And others would probably miss updates, lack of notifications or whatever. Could we "break" 9.0 (stable) updates temporarily (and on purpose) by deploying the changes to 9.1 only, to collect some experience and validate the mechanism? Stable doesn't get updated often anyway. |
|
I'm okay with that. I will make a forum posting before doing it though. |
|
I was going through the script flow again this evening, it is possible to only direct the folks on the 9.1.0 branch to the new script. I have it written, I just want to run through a couple of different branch tests first. |
|
Is this obsolete by now?... |
|
It would be nice to get all branches on the same packaging. But I suppose that can wait until 9.1 gets released. What would you recommend? |
Agreed. Let's let it mature in 9.1. And when we see 9.1 won't be released any time soon we can still back port. But I'd rather |
|
I CherryPicked them into the 9.0 branch to make this PR. These are the commits that would be needed whenever you are ready. If you want to close this PR that's fine. You can always see it to reference it later. |
Oh, sorry, didn't realise. Great then! When time has come we might want to double check I haven't introduced new relevant changes since. |
|
What's left to do with this PR? It's been a while... |
|
Are you considering merging this or just letting this process shake out when you release 9.1.0? If you want to merge this, as far as I know this will "just" work. (Famous last words) Once LMS is building tcz packages for everything, then there is a small change I'll need to make to the update script that differentiates "release" "stable" and "development" branches. |
|
Let's get this in. Could you please look into getting the branch up to date and resolve conflicts? Thanks! |
|
Okay, I'll get things cleaned up. |
Change regex to match both. Signed-off-by: PaulHermann <[email protected]>
Signed-off-by: PaulHermann <[email protected]>
Signed-off-by: PaulHermann <[email protected]>
Signed-off-by: PaulHermann <[email protected]>
…ethods Signed-off-by: Michael Herger <[email protected]>
…d5.txt files too. Signed-off-by: PaulHermann <[email protected]>
…pdate a one click action. Signed-off-by: Michael Herger <[email protected]>
Signed-off-by: PaulHermann <[email protected]>
a92cb3c to
79f6f86
Compare
|
Okay, This is ready, Just had to update the changelog. I scanned other changes and I don't see anything else that needs cherry picked. What should happen. Once this is merged and a new version is generated, I'll do a test, and then make the change to the update script such that both stable and devel branches are using the prepackaged version. If a user updates before I make the change to the script, it will just build it the old way (Make the extension on demand), with the old version of the scripts. |
michaelherger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
No description provided.