Hi Harbs, I would like to be a release manager as well, but using Chri's implementation which as far as I know is in place. I would like to use his mentioned 3 steps and see how much things I will have to do on my own to make release happen. I know that I will have to do that on Mac, cause there some Maven/Git/Jenkins related plugin which allows use Jenkins, but it prevents me from pushing artifacts from windows.
I have some thoughts about above proposition, but I will wait till we all pass trough the release process. Thanks, Piotr czw., 28 maj 2020 o 11:06 Christofer Dutz <[email protected]> napisał(a): > Hi Harbs, > > makes sense. > > Chris > > > > Am 28.05.20, 10:48 schrieb "Harbs" <[email protected]>: > > Hi Chris, > > Thanks for you work helping with the 0.9.7 release as well. > > I’m definitely open to improving the structure and the process. > > My biggest hesitation is that I don’t understand the current release > process well enough. Until recently Alex was the only one who really > understood it. Yishay just went through the process so he has a good > understanding now. I plan on doing another release the week following next > (i.e. starting June 7 or so). My hope is that I will understand it better > at that point. I don’t know whether Greg Dove is willing to do a release, > but I think it would be very valuable to get his input as well. > > So my proposal is that we get some more of us familiar with the what > and the why of the current process. I want to understand what was done and > why it was done. I don’t feel comfortable having an opinion on changing > things until I can weigh the pros and cons. I’d like more of us to be in > the same position so we will be in the position of building consensus on > changes. The reason I hope that Greg Dove specifically does a release is > because I feel he’s pretty neutral on technology and I think he’ll have > good valuable input. > > So here’s my proposal: > > 1. Let’s work on doing another 2-3 releases in rapid succession > without making too many changes. > 2. Let’s try and get as many of us familiar with that process as > possible. > 3. Once that’s done, let’s discuss the pain points and what can be > done to improve the structure and/or the process with pros and cons. Maybe > your suggestion is the way to go? Maybe something else? Similar? Don’t > know, but I’d like to get to the point where we can have an intelligent > discussion on the topic with different points of view. I don’t think we’re > quite there yet. > 4. Carefully start implementing changes. Making big changes is often > disruptive and is often the cause of conflict. This is nothing specific to > us, and there’s even accepted advice on the topic. I suggest we all read > and follow James Duncan Davidson's “rules for revolutionaries”[1]. > > I appreciate having your proposed changes to ponder the next couple of > weeks. > > In the meantime, please by all means, dive into Royale and create > issues, pull requests, let us know difficulties, etc. I’ll make my best > effort to be as responsive as possible and help where I can. If you’re > feeling frustration, please reach out to me on Slack. > > Does this make sense? > Harbs > > [1]http://s.apache.org/rules_for_revolutionaries < > http://s.apache.org/rules_for_revolutionaries> > > > On May 28, 2020, at 10:56 AM, Christofer Dutz < > [email protected]> wrote: > > > > Hi all, > > > > congrats to the successful release of 0.9.7 … it greatly simplified > the last PLC4X release to have the artifacts out there in the wild. > > > > I would really like to see Royale as the tool in my toolbox for > building industrial UI applications as I sort of am not that happy with the > other existing alternatives. > > > > In order to do this I know that I have some areas of expertise I can > offer to the project … Writing ActionScript and MXML code is definitely not > where I can help best. > > > > However I’m really good at Java, Maven and Apache Infrastructure. I > know that development is most active in the ASJS repo but I would be happy > to help on the other sides ... perhaps even help the automated testing in > the ASJS repo. > > > > I would have one proposal on how to really simplify things, but I > would be hesitant to start working on this before we have consensus on this > here. > > It would probably involve multiple weeks of full time work in total > to do it for me, but I would be happy to do it, if the project would accept > it in the end and you folks would be willing to help with the parts I’m not > too deep into (Ant-, NPM build adjustments). So that’s why I’m bringing > this up here first. I know it might question some unwritten project rules, > but I would kindly ask you to not just block the discussion and perhaps > help re-evaluating why they became “project rules” and if the assumptions > were correct or still apply. > > > > The benefit would be: > > > > * Less problems in getting set-up (just clone one repo) > > * Simpler release (Only need to release one repository … no > updating of version information in-between) > > * Less things that can go wrong (I remember when compiler was > already in 0.9.8-SNAPSHOT but the rest wasn’t yet … there were issues > discussed on the list) > > * I would use the opportunity to clean up some things in the > maven build, because despite the probably common assumption … I’m not > really happy with the usability of the maven build from a user’s > perspective … I think there’s great room for improvement > > > > In general I would propose to merge all 3 repositories into one. > Right now the Maven build would probably work with different releases of > the compiler or typedefs but from what I can see … the Ant release would > probably not work without modification. So the whole idea of releasing > separately seems to be more a theoretical one. I think in the history of > FlexJS and Royale it hasn’t been done once (please correct me if I’m > wrong). If there are external entities only interested in consuming parts > of the project, we could build source distribution for these that only > contain the parts they are interest in. > > > > > > * I propose to move the artifacts needed for the build but not > being part of the build (build-tools, jburg-types) into a separate > repository where they can be released independently and don’t cause > confusion like they are doing right now. > > * Then I would like to create a new repository (Let’s call it > “royale”) which contains 3 directories: compiler, typedefs and asjs (or > even with the current “royale-“ prefix, I don’t really care/mind). > > * Now comes the biggest block … I would need to completely > rewrite the royale-maven-plugin … the core of it would be also moved to the > new build-tools repository. This plugin would sort of be an empty skeleton > to load compiler plugins. This is needed as Maven can’t build a project > where a plugin used in the project is also part of the build itself. So we > couldn’t build all-in-one go without this change. > > * Next step would be to add a new royale-parent pom in the new > root of the project, the 3 old parents would be updated to use the new > parent and a lot of duplicated configuration could be moved there, hereby > greatly simplifying the 3 old root poms. > > > > A migration plan, could be to : > > > > * create a feature-branch in all 3 repositories > > * create two new repos “royale” and “royale-build-tools” (or > whatever you want to name them) > > * Start with using git submodules to import the 3 branches into > the new (I know submodules really suck, but they would only be needed until > everything is finished) > > * I would move/copy the build tools to the new repo and start > working on the new maven plugin > > * Then I would need to update the old compiler repo to produce > something I can use as royale-maven-plugin plugins > > * After that’s done I would update the typedefs to use the new > plugin > > * After that’s done I would update the asjs repo to use the new > plugin > > * Then I would add the new royale-parent pom > > * After that’s done I would simplify and deduplicate the > configuration > > * Now I would definitely need some help with adjusting the Ant > and possibly NPM build to these changes (Most of them should be > profile-names and maybe directory names or paths) > > * The last thing that would be required to be done now would be > to remove the submodules in the “royale” repository and to import the real > repos > > * After this the 3 old repos could be archived > > > > I am really looking forward to some open discussion on this. > > > > > > Chris > > > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
