Remove autotools #591
Remove autotools #591
Conversation
This also removes unused papr CI configs TODO: - .gitignore - gtk-doc in CI
|
Can we please have 1.4.3 to fix #593 before version is bumped to dev versions? |
|
@nanonyme Sure, done. |
|
this should at least drop debugedit gitmodule that'd solve #642, meson uses system one or wrap. the libglnx one can be converted to a subtree like flatpak later. |
| license: 'LGPL-2.1-or-later', | ||
| meson_version: '>= 0.56.2', | ||
| version: '1.4.2', | ||
| version: '1.5.0', |
There was a problem hiding this comment.
Would it perhaps make sense to version the development branch as 1.5.0-alpha, 1.5.2-alpha, ..., 1.5.n-rc as proposed in flatpak/flatpak#6014?
There was a problem hiding this comment.
At least I don't have a preference either way
The only thing I want is a) the scheme should be documented in README, b) be consistent between flatpak and flatpak-builder.
There was a problem hiding this comment.
Also, off-topic for this PR but note that distros/people often switch to unstable when some featurework they need lands. The reasoning, often at least for rolling distros etc, is removing deprecated packages from their repos.
IIRC for Flatpak the curl http backend landed in 1.13.x and libsoup2 became deprecated around that time.
Similarly, here libsoup2 removal landed in 1.3.1 and libappstream port landed in 1.3.4. appstream-glib was already deprecated for a long time.
I'm not sure if adding some -alpha, -beta suffix is going to prevent people from doing that.
fdsdk was also tracking Flatpak and Flatpak-builder unstable releases for a long time until I switched it to stable last year. I wasn't around when they started using unstable, so I don't know the exact reasoning behind that, but I do know that the then fdsdk maintainers are/were aware of the odd-even versioning rule.
|
Somebody else should take this over, sorry. |
|
I'll probably take care of it once we start working towards 1.5.0 |
4 participants
This also removes unused papr CI configs
TODO: