Why did maintenance end?

[rhys-vdw]

@pcosgrave Why did you stop maintaining the public repo when this became a package? It was really useful to have this insight into the package. It's almost the worst time to stop given that UPM has git integration. It would be great to be able to maintain a fork and to be able to pull upstream changes from this official repo.

[pcosgrave]

There were a couple reasons the main reason being with the source code available in each editor build "Data\Resources\PackageManager\BuiltInPackages" it is the correct source for each minor version instead of a single drop per major version. To me this is the big "win" for not having the source here on Git, maybe i'm wrong in that thinking i'll ask in the forums if people would still find it useful to have the source updated on git.

Other more minor reason

1. with it being shipped with the Editor (at least currently) without additional work anyways there is no good way to override the included package. You either need to specify a path to a local folder or git both of these seems easier if its user controlled.
2. there are some legal hurdles (I won't get into them here but i'm working on these currently).
3. Time, I was finding I was missing release windows and not always in sync with the latest public release. It also takes a good couple hours to do a public push of the source. Time (at least I feel) is better spent working on quality of life improvements, bugs, and features.

[rhys-vdw]

@pcosgrave thanks for the response!

the source code available in each editor build "Data\Resources\PackageManager\BuiltInPackages" it is the correct source for each minor version instead of a single drop per major version.

Right, well the ideal would be if you were working in git directly then we could see the actual change history. But, even this summarised history is great.

• It's easy to find and navigate
• You can link to specific lines (I've done this a few times in Discord)
• And the main reason I mentioned before: It allows forking and maintenance of a fork by pulling upstream changes.

1. [...] You either need to specify a path to a local folder or git both of these seems easier if its user controlled.

This sounds like the same way all UPM packages are handled right now, unless I'm missing something!

2. there are some legal hurdles [...]

I thought this might be a problem.

3. Time

When I wrote the original comment I had assumed that this was actually the development repo! I realise now it's a public mirror like the code reference.

Anyway, FWIW love that Unity source is on GitHub and to be honest I think it would be amazing if all the official unity packages were available on GitHub -- especially given the move to UPM.

[pcosgrave]

I'm doing what I can to sort through at least all the internal hurdles and get back to pushing changes. This wasn't the first request (and likely wouldnt be the last) So yes its more work for me and as long as people continue to understand its not updated day 1 of a new release if everything goes good internally i'll do some pushes going forward.