So interestingly it's actually possible to have a mono-repo which contains all of the pekko projects as they are now defined with each project being a sbt module within its own sub-folder AND each of those sbt modules having their own version lifecycle. Furthermore it should also be possible for those sub folders to be loaded independently just by cd'ing into the folder.
If its acceptable for Apache in the source distribution to only provide a subset of the sources which are relevant to the module being released at the time, given what was said earlier about each project sub folder being able to loaded on its own this compromise may be able to give us the best of both worlds. On Mon, Aug 7, 2023 at 3:29 PM PJ Fanning <fannin...@apache.org> wrote: > One radical solution that we could consider is starting to merge repos > like pekko-http into the main pekko repo. I know this has drawbacks but it > actually has a few advantages. > > Cons > * This main drawback is that we need to release all the modules in the > main repo at the same time. If we need to fix one module, we need to > release all the modules. Note that many of our repos already have lots of > modules, so all that changes is the number of modules being released at the > same time. > * We would need to refactor the CI so that we don't end up with individual > jobs running too much. We don't want to end up with a build that requires > hours to verify a PR. > > Pros > * For users, it simplifies working out which versions of pekko modules to > use. From the traffic in our online mailing lists and GitHub discussions - > I think a lot of users are confused about why a module like > pekko-connectors-s3 is released separately from pekko-stream and has a > different version number. > * For testing the modules and how they work together, all the jars can be > built into mavenLocal. > * No longer do we need to worry about how to get a pekko-stream change > tested in all the connectors > * For release voting, voters will not to have to work out the specific > circumstances of all the individual git repos that we have. > > This is a lot of work but it may be worth considering. > > > On 2023/08/07 11:17:18 Matthew de Detrich wrote: > > I made my case quite clear before, it breaks past builds if people want > to > > load > > past versions of the project (and when I mean break I really do mean > > break, as in the build won't even load when you check out the source) > > and additionally there are strong arguments that this is a misuse of > > snapshots. > > > > The whole point of milestone is to have a persistent/permanent (this is > > critical) > > artifact that regardless of when someone resolves a build at a specific > > point > > in time they will always be able to load it whether it is now, 5 days, 5 > > months or > > 5 years. If the main reason why uses will want to be loading past builds > to > > try and > > bisect some bug/issue in the past, it's imperative that they do actually > > load the > > code that is relevant back then, not what is published now (because > > snapshots by > > definition only maintain the latest X versions of an artifact's version > Y). > > Of course > > there are ways around this, but this basically involves users having to > > carefully > > and transitively build all relevant dependencies in the dependency tree > and > > the > > careful part here is significant because they need to build the project > the > > same > > way it was built back then (think JDK versions here). > > > > This is why at least to me, using pinned snapshots as core dependencies > > in Pekko modules is not negotiable from my side, I would much prefer > > publishing milestones as part of an Apache's Release process or just > > leave the core dependencies of Pekko as full release versions and create > > a separate branch/CI matrix that dynamically builds the dependencies > > from source and/or loads snapshots to detect regressions (but even > > that has its own host of problems). > > > > The thing is none of the contributors have the capacity to do such > extensive > > changes, the whole point of the milstone solution is it is a trivial and > > clean > > solution to many problems (not just this one, bringing up > > > https://github.com/apache/incubator-pekko/pull/532#issuecomment-1667527994 > > again). It massively simplifies the code, makes it trivially easy for > pekko > > contributors to understand what is going on (i.e. no complex dynamically > > finding > > out the latest snapshot as is done in > pekko-http/pekko-persistence-dynamodb) > > and doesn't have hair pulling gotchas like "why isn't this build loading, > > oh great > > the snapshot is deleted because it was pruned so now I have to figure out > > how > > that snapshot was built and do it all myself". > > > > Other Apache projects can use snapshots in this way, and that's fine but > > Pekko > > already has enough issues with overburdening complexity and gotchas that > is > > making the project less approachable for contributors and using pinned > > snapshots in this way just makes it worse. > > > > On Mon, Aug 7, 2023 at 12:14 PM Claude Warren, Jr > > <claude.war...@aiven.io.invalid> wrote: > > > > > Matthew, your argument makes no sense to me. Let me see if I can > restate > > > it to be sure I have the salient points. > > > > > > 1. There are two modules, let's call them "core" and "child". > > > 2. There is a version where core and child work together. Let's > call > > > this 1.0.0 for both. I realize they can be different, but I want to > > > keep > > > this as simple as possible. > > > 3. Now core develops a new version that has a change that may cause > a > > > regression. let's call this core-1.1.0-S1. > > > 4. The problem is we want "child" to be able to test against > > > core-1.1.0-S1 to verify that there are no regression issues. So > for the > > > immediate problem:, > > > 1. "child" can create a branch that tests against core-1.1.0-S1. > > > Let's call this version child-1.1.0-regression (it has to be the > next > > > version of child because 1.0.0 is already released -- it could > > > be 1.0.1 but > > > I'm not going there) > > > 5. If there is a regression: > > > 1. that information will flow back to core dev and core-1.1.0-S2 > will > > > be created > > > 2. "child" can then test against that in child-1.1.0-regression. > > > 3. In this case child-1.1.0-regression wants to test with the > latest > > > core-1.1.0-Sx version. > > > 6. If there was no regression there might be when core-1.1.0-S2 is > > > published. > > > 1. In this case child-1.1.0-regression should be run > > > against core-1.1.0-S2 > > > 2. again "child" wants to run against the latest "core-1.1.0-Sx". > > > 7. For both of the above paths the standard core-1.1.0-SNAPSHOT > fits the > > > bill. > > > 8. At some point "child" dev has to decide to go with core-1.1.0 > (after > > > it is released) or core-1.0.0 but that is a decision for "child" and > > > either > > > will work (assuming child has no dependency on functionality > introduced > > > in > > > core-1.1.0). > > > 9. After core-1.1.0 is released core-1.1.0-Sx is deleted from the > > > repository, because it is a snapshot. And this leads to the issue. > > > 10. At some later time someone wants to checkout > > > "child-1.1.0-regression" and have it build, but can not because > > > "core-1.1.0-Sx" is no longer found. There are 2 cases here: > > > > > > > > > 1. There is some issue being checked that does not involve the > changes > > > in core-1.1.0 at this moment in time, in which case core-1.1.0 > > > (release) > > > can replace core-1.1.0-Sx. > > > 2. There is some issue being checked with the regression tests > for > > > core-1.1.0-Sx. This feels like a very low probability issue but, > > > let's > > > move forward with this discussion. > > > 1. At this point, the developer can checkout the core-1.1.0 > code > > > for the time frame in question and build it thus providing the > > > library > > > necessary for the analysis they are performing. > > > 1. Is this solution optimal - no. > > > 2. Is it acceptable? In my opinion looking at > cost/benefit, I > > > think so. The probability that anyone will want to > rebuild > > > child-1.1.0-regression is low. In every case I can think > of > > > 1. working with child-1.1.0 is the better solution as > that > > > is the code that was finally accepted to release, or > > > 2. if not released at least the accepted snapshot. > > > 3. If development on "child" has stalled and someone is > > > picking it up again and the most advanced code is in > > > "child-1.1.0-regression" then they need to move the > > > dependency to > > > core-1.1.0 (if not later) and work forward from there. > > > > > > I make some assumptions here: > > > > > > - Snapshot versions are retained in the repository by count as well > as > > > date so the last 5 or last 5 days whichever is greater sort of > thing. > > > - Snapshot versions are deleted when a release is made. > > > - I do not assume that child-1.1.0 will be released just > > > because core-1.1.0 is released, the regression check was just that > and > > > does > > > not imply the version of core that will be used in child-1.1.0. > There > > > is > > > some argument to be made that the child regression check should be > > > core-child-1.1.0-regression and that it should be the > responsibility of > > > the > > > core developers to make the test. But that is neither here nor > there as > > > the test is assumed to have been made for purposes of this > discussion. > > > - There is nothing stopping the "child" team from preserving any > version > > > of core-1.1.0-Sx that they wish to retain for testing or other uses, > > > provided they don't release it. > > > > > > So if there is any disagreement please let me know which bullet number > > > (and/or sub numbers) you disagree with and why. > > > > > > > > > On Mon, Aug 7, 2023 at 8:49 AM Matthew de Detrich > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > I think that there is a communication probleem; crossed wires in > > > > terminology. Matthew talks about "general public" and most of us > grey > > > > heads (trying not to be gender specific here) in the ASF hear > "release". > > > > What I think Matthew is talking about is a wider testing audience. > > > People > > > > who understand that the code is not "released". If that is > > > > indeed the case, and I am certain Matthew will tell me if I am wrong, > > > then > > > > the following should make sense. > > > > > > > > Yes this is completely correct > > > > > > > > > Use the snapshot repositories to their fullest. > > > > > > > > This is actually where the problem lies. We are already deploying > into > > > > snapshots > > > > (see > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/ > > > ). > > > > The problem is that due to the way snapshots are being deployed > currently > > > > they > > > > are not being pruned and INFRA has actually approached us saying > that at > > > > some point we need to fix this. In summary we cannot rely on > snapshots > > > > being > > > > persistent, they are designed to be pruned. > > > > > > > > Now while this may be fine for a wider general testing audience, it > does > > > > pose > > > > other issues if we were to use snapshots to solve other issues, i.e. > > > > testing > > > > merged changes in pekko main in other modules. Let me demonstrate > what I > > > > mean by this > > > > > > > > * Pekko merges some significant feature, lets say the upgrade from > netty3 > > > > to > > > > netty4 (which is a very good example) i.e. > > > > https://github.com/apache/incubator-pekko/pull/539 > > > > * Since this is a major we want to make sure that it doesn't cause > > > > unintended > > > > regressions in other pekko modules, such as pekko-management > > > > * This means that ideally we would like to update the pekko version > in > > > > pekko-management to a version of pekko that has the netty3->netty4 > change > > > > so we can catch problems well before a release is made > > > > > > > > Now we could update the pekko dependency in pekko-management to use > > > > a snapshot but as stated before the snapshot's are not meant to be > > > > persistent. > > > > This leaves us with the next best solution which is to use a > milestone > > > > which > > > > is designed to persist (unlike a snapshot). When enough significant > > > changes > > > > get merged into Pekko, one of the PPMC/committers will notify > developers > > > > that a milestone is being published and when a milestone is > published we > > > > can just update the dependency in pekko-management to that milestone. > > > > > > > > Now of course there are other solutions to this, i.e. pekko-http and > > > > pekko-persistence-dynamodb happen to have code that will > > > > dynamically find the latest snapshot from Apache Maven Snapshots > > > > repository but this causes its own problems (see the conversation > > > > at > > > > > > > > > > > > https://github.com/apache/incubator-pekko-http/issues/293#issuecomment-1666893217 > > > > ). > > > > The other solutions mentioned, i.e. using the nightlies repository > also > > > are > > > > less than ideal solutions i.e. publishing to nightlies repository > > > > requires us to manually deploy locally and move the jars via rsync > which > > > is > > > > quite > > > > brittle (i.e. the build will break whenever a folder structure > changes). > > > > More > > > > generally projects have actually been moving away from deploying jars > > > into > > > > the nightlies repository because it's not the correct place to put > > > them[1], > > > > the > > > > nighlies repository is more suited to binary applications builds > (think > > > > executables for Apache OpenOffice) > > > > > > > > Deploying milestone jars will also happen to solve > > > > > > > > https://github.com/apache/incubator-pekko/pull/532#issuecomment-1664741546 > > > > very > > > > cleanly. > > > > > > > > This is what I meant earlier when I said these are largely technical > > > > problems. > > > > > > > > [1]https://lists.apache.org/thread/t6598v7lsdb74q65x9grwhxqt38ntq2s > > > > > > > > On Mon, Aug 7, 2023 at 8:17 AM Claude Warren, Jr > > > > <claude.war...@aiven.io.invalid> wrote: > > > > > > > > > Here is my take on this discussion. Please stick with me for a > bit. > > > > > > > > > > I think that there is a communication probleem; crossed wires in > > > > > terminology. Matthew talks about "general public" and most of us > grey > > > > > heads (trying not to be gender specific here) in the ASF hear > > > "release". > > > > > What I think Matthew is talking about is a wider testing audience. > > > > People > > > > > who understand that the code is not "released". If that is > > > > > indeed the case, and I am certain Matthew will tell me if I am > wrong, > > > > then > > > > > the following should make sense. > > > > > > > > > > > > > > > - Pekko can build and place into the SNAPSHOT repository, > nightly > > > > > builds. These builds should be named > > > <pekko-module>-x.y.z-SNAPSHOT. > > > > > The > > > > > repository will take care of adding dates to them to ensure the > > > > > latest SNAPSHOT is returned. (The repository should also > > > > automatically > > > > > retain only 5 or so snapshots for pekko-module-x.y.z but that > is a > > > > > different issue) > > > > > - Pekko can build and place into the SNAPSHOT repository, a > longer > > > > > period (weekly,monthly) or manually triggered build that has a > name > > > > like > > > > > <pekko-module>-x.y.z-M-SNAPSHOT. Where "M" is the literal 'M'. > > > This > > > > > will > > > > > have the same retention properties as > <pekko-module>-x.y.z-SNAPSHOT. > > > > > - The "wider testing audience" needs to be pointed to the dev > > > mailing > > > > > list. There are several reasons for this, most notably: They > have > > > > > access > > > > > to the discussion about what is changing, they can be notified > when > > > an > > > > > "M" > > > > > release is created, they can contribute ideas, suggestions and > > > > concepts > > > > > back to the community, they become part of the community. > > > > > - The "wider testing audience" can depend upon > > > > > <pekko-module>-x.y.z.M-SNAPSHOT during their builds, provided > they > > > add > > > > > the > > > > > ASF snapshot repository. > > > > > - There is no "release" here, all work is in the "dev" side of > the > > > > > house. > > > > > - The pekko dev team can produce Milestone ("M") builds when > they > > > > > desire, but may need to do manual cleanup of the repository > when the > > > > > actual > > > > > release is made. > > > > > - The pekko dev team can produce Regression ("R") builds that > > > perform > > > > > extensive regression testing if so desired. > > > > > - The pekko dev team can produce Foo ("F") builds to ensure foo > > > > > correctness (whatever that is) if so desired. > > > > > - The pekko dev team will need to clean up all the lettered > versions > > > > > when the release is made or Infra will become very annoyed. > > > > > - The pekko dev team should try to limit the number of lettered > > > > versions > > > > > so that infra does not become annoyed. > > > > > > > > > > The short bit here is that as long as the work is development work > > > > > (building, testing, and verification) and not for the "general > public" > > > > > (grey head definition) then it can safely be done and "released" > > > > (non-grey > > > > > head definition) within the dev environment (source, build, > repository, > > > > and > > > > > community tools). > > > > > > > > > > My recommendations are: > > > > > > > > > > - Bring the "wider testing audience" into the dev conversations. > > > > > - Announce milestone builds and internal releases in the dev > list. > > > > > - Use the snapshot repositories to their fullest. > > > > > - expand the pool of potential team members. > > > > > > > > > > That last point brings me to the other topic of PPMC members, and I > > > > > apologize for not seeing and paying attention to the discussion on > the > > > > > private list and will endeavour to do better in future. > > > > > > > > > > Claude > > > > > > > > > > On Sun, Aug 6, 2023 at 4:01 PM Matthew de Detrich > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > I agree with all of Justin McLean's points. > > > > > > > > > > > > > I care about the ASF rules > > > > > > > > > > > > I am still waiting for an actual reference to a rule on this and > > > Justin > > > > > > appears to have misunderstood what was being suggested (but I > > > > > > will wait for his answer) > > > > > > > > > > > > > and norms. > > > > > > > > > > > > I have seen more than non negligible amount of so-called "norms" > > > > > > which turn out to be either false or some convention which > projects > > > > > > copy from other projects just because. Pekko is also not a > typical > > > > > > project in this specific regard, which by definition means its > not > > > > > > normal so I in this case I don't about norms unless there is a > rule > > > > > > behind it. > > > > > > > > > > > > > > > > > > On Sun, Aug 6, 2023 at 3:48 PM PJ Fanning <fannin...@apache.org> > > > > wrote: > > > > > > > > > > > > > I agree with all of Justin McLean's points. > > > > > > > > > > > > > > I absolutely don't care what non-ASF projects do. I care about > the > > > > ASF > > > > > > > rules and norms. > > > > > > > > > > > > > > On Sun, 6 Aug 2023 at 14:44, Matthew de Detrich > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > I remain strongly opposed to publishing to maven central > > > without > > > > a > > > > > > > > full release process with 2 phase voting. > > > > > > > > > > > > > > > > Can you elaborate on this opposition? There is plenty of > software > > > > > that > > > > > > is > > > > > > > > distributed on maven using commonly established milestone > suffix > > > > > > > > (i.e. -M0, -M1 etc etc) and I would argue it's far from > > > > controversial > > > > > > to > > > > > > > > state that it's extremely clear for users that such an > artifact > > > is > > > > a > > > > > > > > milestone, this is already established. > > > > > > > > > > > > > > > > I just want to know where you are coming from, because if > it's > > > just > > > > > due > > > > > > > > to it being a rule/Apache process this is what I want to > clarify > > > > (if > > > > > > > there > > > > > > > > is a clear specific rule on this that this is not allowed; > which > > > > has > > > > > > yet > > > > > > > > to be provided yet then yes I will drop it). > > > > > > > > > > > > > > > > On Sun, Aug 6, 2023 at 3:30 PM PJ Fanning < > fannin...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > > > I remain strongly opposed to publishing to maven central > > > without > > > > > full > > > > > > > > > release process with 2 phase voting. > > > > > > > > > > > > > > > > > > I can live with putting milestone jars elsewhere like > > > > > > > > > nightlies.apache.org. We used to have a CI job that > published > > > > jars > > > > > > to > > > > > > > > > nightlies.apache.org. This can easily be dusted down and > > > > > repurposed. > > > > > > > > > My vague recollection was that the jars were published in a > > > Maven > > > > > > repo > > > > > > > > > compatible data structure so that they were easily > consumable > > > in > > > > > > > > > mvn/gradle/sbt builds. > > > > > > > > > > > > > > > > > > On Sun, 6 Aug 2023 at 14:18, Matthew de Detrich > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > > > > And we can release voted on milestones. > > > > > > > > > > > > > > > > > > > > We can but for reasons stated earlier this to me seems > like a > > > > > > bandaid > > > > > > > > > > and as you pointed out in [1] we are having issues > currently > > > > with > > > > > > > getting > > > > > > > > > > enough votes for releases. Hence my biggest complaint > here is > > > > > that > > > > > > > > > > requiring votes sends the wrong signals, after all one > of the > > > > > main > > > > > > > points > > > > > > > > > > of my suggested use of milestones is to test published > > > > milestones > > > > > > in > > > > > > > > > > downstream modules to confirm that they are suitable for > > > > general > > > > > > > public > > > > > > > > > > consumption which is the point that Justin raised > earlier. > > > > > > > > > > > > > > > > > > > > > In the meantime, we have: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/PEKKO/Testing+with+Pekko+Snapshot+Jars > > > > > > > > > > > > > > > > > > > > > Which is not ideal but it does provide some help. > > > > > > > > > > > > > > > > > > > > While this is (for now) fine at least for one case (i.e. > > > > > > > users/developers > > > > > > > > > > testing quick changes which is intended use for > snapshots) it > > > > > > doesn't > > > > > > > > > > practically alleviate the other case regarding testing > > > > downstream > > > > > > > pekko > > > > > > > > > > modules with more recent upstream pekko changes. > > > > > > > > > > > > > > > > > > > > Using snapshots for this means we have to continuously > > > > add/remove > > > > > > > > > > the Apache Nexus snapshot repository in the downstream > > > modules > > > > > > build > > > > > > > > > > files. > > > > > > > > > > > > > > > > > > > > This point in general actually becoming increasingly more > > > > > important > > > > > > > now > > > > > > > > > > considering we are getting significant changes merged > > > upstream > > > > in > > > > > > the > > > > > > > > > > Pekko 1.1.x series and our current approach of only > bringing > > > in > > > > > the > > > > > > > > > > changes when a release candidate is being voted on means > that > > > > > > > > > > we will be bringing in ~6-12 months of changes all at > once at > > > > an > > > > > > > > > > inopportune time (i.e. a release is being made) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > https://lists.apache.org/thread/b57nmyrg5xhgdv3gnbq2o9s6wsqf31q6 > > > > > > > > > > > > > > > > > > > > On Sun, Aug 6, 2023 at 2:57 PM PJ Fanning < > > > > fannin...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > And we can release voted on milestones. > > > > > > > > > > > > > > > > > > > > > > In the meantime, we have: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/PEKKO/Testing+with+Pekko+Snapshot+Jars > > > > > > > > > > > > > > > > > > > > > > Which is not ideal but it does provide some help. > > > > > > > > > > > > > > > > > > > > > > On Sun, 6 Aug 2023 at 13:38, Matthew de Detrich > > > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Nobody is threatening to delete our recent > snapshots. > > > > There > > > > > > is > > > > > > > a > > > > > > > > > > > > question about what to do about older snapshots - > which > > > is > > > > > > > separate > > > > > > > > > > > > from this topic. > > > > > > > > > > > > > > > > > > > > > > > > I am not saying that people will be deleting our > > > snapshots, > > > > > but > > > > > > > > > rather > > > > > > > > > > > > there is a current problem with them being pruned (or > > > more > > > > > > > correctly > > > > > > > > > > > > not being pruned as expected) which needs to be > resolved. > > > > > > > > > > > > > > > > > > > > > > > > > Anyone who wants to test the latest pekko 1.1.0 > preview > > > > can > > > > > > > track > > > > > > > > > down > > > > > > > > > > > > versions at > > > > > > > > > > > > The core point is while its possible for users to > > > manually > > > > > > track > > > > > > > > > > > snapshots > > > > > > > > > > > > and update them as new ones get released/old ones get > > > > deleted > > > > > > > this > > > > > > > > > is not > > > > > > > > > > > > practical for the use case I mentioned earlier where > we > > > > want > > > > > to > > > > > > > set > > > > > > > > > the > > > > > > > > > > > > downstream Pekko modules versions to a more > frequently > > > > built > > > > > > non > > > > > > > > > release > > > > > > > > > > > > version so we can catch regressions and/or make sure > that > > > > > newly > > > > > > > > > merged > > > > > > > > > > > > features work as expected. > > > > > > > > > > > > > > > > > > > > > > > > If we use snapshots for this then we have the > overhead of > > > > > > having > > > > > > > to > > > > > > > > > > > > manually update snapshots versions when builds break > due > > > to > > > > > > > > > > > > snapshots not existing anymore (note that this hasn't > > > been > > > > a > > > > > > > problem > > > > > > > > > for > > > > > > > > > > > now > > > > > > > > > > > > because the snapshot pruning is not working correctly > > > which > > > > > is > > > > > > > the > > > > > > > > > > > problem > > > > > > > > > > > > I was referring to before). > > > > > > > > > > > > > > > > > > > > > > > > Furthermore if developers want to test newly merged > > > > features > > > > > > into > > > > > > > > > > > > development/staging/prod systems to see that there > aren't > > > > > > > > > regressions, > > > > > > > > > > > > assuming the snapshots are working correctly (which > they > > > > > > > currently > > > > > > > > > > > aren't) > > > > > > > > > > > > they can also hit the same issues regarding the > snapshots > > > > > being > > > > > > > > > pruned. > > > > > > > > > > > > > > > > > > > > > > > > At least to me, this is one of the core problems > that the > > > > > > > milestone > > > > > > > > > > > > concept is intended to solve, snapshots are too > > > > > > > frequent/granular and > > > > > > > > > > > > releases/release candidates are too infrequent. > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Aug 6, 2023 at 2:23 PM PJ Fanning < > > > > > > fannin...@apache.org> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Nobody is threatening to delete our recent > snapshots. > > > > There > > > > > > is > > > > > > > a > > > > > > > > > > > > > question about what to do about older snapshots - > which > > > > is > > > > > > > separate > > > > > > > > > > > > > from this topic. > > > > > > > > > > > > > > > > > > > > > > > > > > Anyone who wants to test the latest pekko 1.1.0 > preview > > > > can > > > > > > > track > > > > > > > > > down > > > > > > > > > > > > > versions at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-actor-typed_2.13/ > > > > > > > > > > > > > > > > > > > > > > > > > > 1.1.0-M0+5-964dcf53-SNAPSHOT is the most recent - > but > > > > there > > > > > > > will be > > > > > > > > > > > > > new snapshots published most nights (any day that > has > > > > > commits > > > > > > > to > > > > > > > > > the > > > > > > > > > > > > > main branch). > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 6 Aug 2023 at 13:08, Matthew de Detrich > > > > > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question to ask is, will these artefacts be > > > used > > > > by > > > > > > > users > > > > > > > > > or > > > > > > > > > > > > > intended > > > > > > > > > > > > > > for their use? i.e. people who are not > subscribed to > > > > the > > > > > > > mailing > > > > > > > > > > > list or > > > > > > > > > > > > > > not committers or PMC members? If so, then by ASF > > > > > > definition, > > > > > > > > > that > > > > > > > > > > > > > artefact > > > > > > > > > > > > > > is a release and needs to be voted on by the > > > PPMC/IPMC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > No they aren't, as I said they are treated in the > > > exact > > > > > > same > > > > > > > way > > > > > > > > > > > > > snapshots > > > > > > > > > > > > > > are currently treated. The **ONLY** difference is > > > that > > > > > they > > > > > > > will > > > > > > > > > be > > > > > > > > > > > > > > distributed to the Apache Nexus main repository > and > > > > this > > > > > is > > > > > > > > > mainly > > > > > > > > > > > due to > > > > > > > > > > > > > > technical reasons stated before (i.e. snapshots > are > > > > > > > > > semi-permanent > > > > > > > > > > > since > > > > > > > > > > > > > > they need to be pruned). > > > > > > > > > > > > > > > > > > > > > > > > > > > > The primary motivation for the milestone > artifacts > > > are > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Internal testing between the Pekko dependencies > > > (i.e. > > > > > > > > > publishing an > > > > > > > > > > > > > > artifact of Pekko core and using that artifact > in in > > > > > other > > > > > > > Pekko > > > > > > > > > > > modules > > > > > > > > > > > > > to > > > > > > > > > > > > > > catch regressions before a release is marked) > > > > > > > > > > > > > > * For Pekko developers to have the ability to > test > > > > their > > > > > > > features > > > > > > > > > > > which > > > > > > > > > > > > > > were merged into main in their production systems > > > > without > > > > > > > having > > > > > > > > > to > > > > > > > > > > > > > > manually build Pekko (and possibly all of Pekko's > > > > > > > dependencies) > > > > > > > > > > > > > themselves, > > > > > > > > > > > > > > which also as stated previously is quite > difficult > > > > > > > > > > > > > > > > > > > > > > > > > > > > There is no intention of the milestones having > any > > > > formal > > > > > > > release > > > > > > > > > > > > > > announcement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Have other incubating projects made non-ASF > > > releases > > > > > > while > > > > > > > in > > > > > > > > > > > > > incubation? > > > > > > > > > > > > > > In a small number of cases, yes, mostly while > they > > > were > > > > > > > getting > > > > > > > > > their > > > > > > > > > > > > > code > > > > > > > > > > > > > > base in order but not after they had made an ASF > > > > release, > > > > > > and > > > > > > > > > there > > > > > > > > > > > we > > > > > > > > > > > > > very > > > > > > > > > > > > > > clearly labelled as non-ASF releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes and this is not meant to be a formal ASF > release, > > > > > hence > > > > > > > the > > > > > > > > > > > previous > > > > > > > > > > > > > > suggestion of making this clear even in the > > > DISCLAIMER > > > > > file > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re official documentation/process that > describes > > > this > > > > > > > > > distinction? > > > > > > > > > > > Yes, > > > > > > > > > > > > > > that policy page sets that out. See, for > instance [1] > > > > and > > > > > > > [2] for > > > > > > > > > > > why it > > > > > > > > > > > > > > needs to be this way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] Is talking about source packages, this > discussion > > > > is > > > > > > > about > > > > > > > > > binary > > > > > > > > > > > > > > artifacts. In the last line they mention this > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nightly Builds that are not release candidates > can > > > be > > > > > > > hosted at > > > > > > > > > > > > > > ci.apache.org projects area, just file an INFRA > > > > ticket. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The links to ci.apache.org aren't even working > and I > > > > > doubt > > > > > > > we > > > > > > > > > can > > > > > > > > > > > even > > > > > > > > > > > > > use > > > > > > > > > > > > > > such a repository since we are dealing with JVM > jar's > > > > > > > > > specifically > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re official documentation/process that > describes > > > this > > > > > > > > > distinction? > > > > > > > > > > > Yes, > > > > > > > > > > > > > > that policy page sets that out. See, for > instance [1] > > > > and > > > > > > > [2] for > > > > > > > > > > > why it > > > > > > > > > > > > > > needs to be this way. The Incubator distribution > > > > > guideline > > > > > > > also > > > > > > > > > > > covers > > > > > > > > > > > > > this > > > > > > > > > > > > > > [3]. You see that at [4] "Release candidates, > > > nightlys > > > > > and > > > > > > > > > snapshots > > > > > > > > > > > must > > > > > > > > > > > > > > not be advertised to the general public.” and > you can > > > > > read > > > > > > > [5] > > > > > > > > > for > > > > > > > > > > > why. > > > > > > > > > > > > > The > > > > > > > > > > > > > > release distribution policy also touches on this > e.g. > > > > [6] > > > > > > > > > > > > > > > > > > > > > > > > > > > > As was clarified earlier, milestones are **NOT** > > > > > releases, > > > > > > > they > > > > > > > > > are > > > > > > > > > > > > > treated > > > > > > > > > > > > > > the exact same way as snapshots, nightlies or > release > > > > > > > candidates > > > > > > > > > > > with the > > > > > > > > > > > > > > **ONLY** critical difference being that they are > > > > deployed > > > > > > in > > > > > > > a > > > > > > > > > > > repository > > > > > > > > > > > > > > that is not snapshots and they are published less > > > > > > frequently > > > > > > > > > then a > > > > > > > > > > > > > > snapshot/nightly is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > With this being said I am increasingly of the > opinion > > > > > that > > > > > > > this > > > > > > > > > is > > > > > > > > > > > more > > > > > > > > > > > > > of > > > > > > > > > > > > > > a technical INFRA question than an ASF policy > > > question > > > > > > since > > > > > > > the > > > > > > > > > > > issues > > > > > > > > > > > > > > being discussed are technical in nature. There > was > > > > never > > > > > a > > > > > > > > > > > suggestion of > > > > > > > > > > > > > > making an alternative formal type of ASF release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Aug 6, 2023 at 10:51 AM Justin Mclean < > > > > > > > > > > > jus...@classsoftware.com> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question to ask is, will these artefacts be > > > used > > > > by > > > > > > > users > > > > > > > > > or > > > > > > > > > > > > > intended > > > > > > > > > > > > > > > for their use? i.e. people who are not > subscribed > > > to > > > > > the > > > > > > > > > mailing > > > > > > > > > > > list > > > > > > > > > > > > > or > > > > > > > > > > > > > > > not committers or PMC members? If so, then by > ASF > > > > > > > definition, > > > > > > > > > that > > > > > > > > > > > > > artefact > > > > > > > > > > > > > > > is a release and needs to be voted on by the > > > > PPMC/IPMC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Have other incubating projects made non-ASF > > > releases > > > > > > while > > > > > > > in > > > > > > > > > > > > > incubation? > > > > > > > > > > > > > > > In a small number of cases, yes, mostly while > they > > > > were > > > > > > > getting > > > > > > > > > > > their > > > > > > > > > > > > > code > > > > > > > > > > > > > > > base in order but not after they had made an > ASF > > > > > release, > > > > > > > and > > > > > > > > > > > there we > > > > > > > > > > > > > very > > > > > > > > > > > > > > > clearly labelled as non-ASF releases. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re official documentation/process that > describes > > > this > > > > > > > > > distinction? > > > > > > > > > > > Yes, > > > > > > > > > > > > > > > that policy page sets that out. See, for > instance > > > [1] > > > > > and > > > > > > > [2] > > > > > > > > > for > > > > > > > > > > > why > > > > > > > > > > > > > it > > > > > > > > > > > > > > > needs to be this way. The Incubator > distribution > > > > > > guideline > > > > > > > also > > > > > > > > > > > covers > > > > > > > > > > > > > this > > > > > > > > > > > > > > > [3]. You see that at [4] "Release candidates, > > > > nightlys > > > > > > and > > > > > > > > > > > snapshots > > > > > > > > > > > > > must > > > > > > > > > > > > > > > not be advertised to the general public.” and > you > > > can > > > > > > read > > > > > > > [5] > > > > > > > > > for > > > > > > > > > > > > > why. The > > > > > > > > > > > > > > > release distribution policy also touches on > this > > > e.g. > > > > > [6] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kind Regards, > > > > > > > > > > > > > > > Justin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > https://www.apache.org/legal/release-policy.html#host-rc > > > > > > > > > > > > > > > 2. > > > > > https://www.apache.org/legal/release-policy.html#why > > > > > > > > > > > > > > > 3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/Distribution+Guidelines > > > > > > > > > > > > > > > 4. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://incubator.apache.org/guides/distribution.html#release_platforms > > > > > > > > > > > > > > > 5. > > > > > > > > > > > > > > > > https://incubator.apache.org/guides/distribution.html#motivation > > > > > > > > > > > > > > > 6. > > > > > > > https://infra.apache.org/release-distribution.html#maven > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > To unsubscribe, e-mail: > > > > > dev-unsubscr...@pekko.apache.org > > > > > > > > > > > > > > > For additional commands, e-mail: > > > > > > dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu > Valtonen > > > > > > > > > > > > > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > To unsubscribe, e-mail: > > > dev-unsubscr...@pekko.apache.org > > > > > > > > > > > > > For additional commands, e-mail: > > > > dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@pekko.apache.org > > > > > > > > > > > For additional commands, e-mail: > dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
