Hi Piotr, we could change the configuration to use the jgit plugin on the CI machine and to use the default on local machines. In that case you could do it on any machine you want (also windows)
Who does releases in which order using which tooling ... I don't really care ... I'm just happy that there's a line building up of people wanting to do so and I get to use fresh releases :-) If there is anything I can help with ... just ping me and I'll be happy to help. Chris Am 28.05.20, 13:18 schrieb "Piotr Zarzycki" <[email protected]>: 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>*
