Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cocoapods update #1223

Closed
PierreCapo opened this issue Feb 1, 2023 · 5 comments
Closed

Cocoapods update #1223

PierreCapo opened this issue Feb 1, 2023 · 5 comments

Comments

@PierreCapo
Copy link

Hello,
@NickGerleman Many thanks for working again on this library, that is fantastic 馃榾.

I am using this library on some projects and I wanted to know if it would be possible to update the Cocoapods release with the last changes made?

Let me know if somehow I can help.
Many thanks, have a good day!

@NickGerleman
Copy link
Contributor

NickGerleman commented Feb 8, 2023

I've been eyeing a new release on Maven, Cocoapods, and NPM. A lot has gotten crusty since the older ones, so I've been hoping to get us into a place where everything is working before we push the newer revision.

The JS package is relatively good-to-go compared to the others in terms of code/config. I also did some work recently to update the Gradle/Android build logic to be less crusty. Though tests for it have long been broken, and need to be turned on before we do a release (even a beta) imo. Right now we don't have the sample app using Gradle either, which we'd need to manually validate things. There was a change to do that, but I think I will need to reimplement it on top of the new changes.

I have had less context into the Apple build, and the work we should be doing to modernize the YogaKit and Yoga pods. There are a lot of PRs here, but I haven't had the context to evaluate them as being correct against current XCode, or the reference build. I added some coverage for pod spec lint or pod install of the sample project, but it is currently effectively disabled.

If you want to help, making fixes to its build which light things up would definitely be appreciated.

I have already started to track down the permissions for existing packages so we can publish them as part of a pipeline. Right now that only exists for the Maven package. There are also many hardcoded version numbers across these I have been trying to find. We should add a versioning script to avoid needing to rely on this. But a copy/paste commit to change all the versions in the repo at once is doable before that.

@nicoburns
Copy link
Contributor

@NickGerleman I feel like a good first step towards new Maven/Cocoapods/NPM releases would be a versioned release (e.g. on Github Releases) of the core C++ library (along with a commitment to maintain a changelog for future versioned releases going forwards). From the point of view of OSS consumers of yoga it's much nicer if for example the npm library says "this release corresponds to vX.Y.Z of yoga" rather than pointing to a git commit id. I figure it's unrealistic to retroactively compile a changelog since the last versioned release back in 2021 (although perhaps a few highlights like gap support could be compiled?), but we could establish a baseline (e.g. v1.20.0) and maintain one from that point onwards.

@NickGerleman
Copy link
Contributor

NickGerleman commented Mar 4, 2023

I think the number of changes is small enough to be able to create a nice small changelog along manually triggered GitHub releases.

We could definitely do a C++ only release, and create a stable-point for that portion of the library. Though so far, I have more often see direct feedback asking for (in order) new revisions on NPM, Cocoapods, Gradle (Also SPM and NuGet but those aren't needed for strict parity). So that C++ only beta release might not benefit folks beyond exercising that we can write a changelog, or make those commitments.

There is also a change I would like to make to the C++ API around a generalized way to handle errata. The current APIs there don't scale, and we should be able to shape the API in a way where we can change default behavior to be conformant, while allowing users to easily choose to opt out. There's an accompanying policy I have been brewing around that.

Given the very long gap in OSS, I do generally want to "have our ducks in a row" before we trigger increased external adoption of the current source tree. So my inclination is to want to make those changes now, and try to do everything nicely at once. Though I realize "perfect" is the enemy of "good", and we do need to get something out soon.

@NickGerleman
Copy link
Contributor

We are now running pod lib lint and building samples as part of CI, and are planning on doing a release later this month.

@NickGerleman
Copy link
Contributor

We've just published Yoga and YogaKit 2.0.0-beta.1 to CocoaPods trunk. Expect a proper release announcement shortly. https://cocoapods.org/pods/Yoga

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants