On Wed, Jan 31, 2024 at 2:39 PM Jon Turney via Cygwin wrote: > > On 21/01/2024 22:13, Brian Inglis via Cygwin wrote: > > On 2024-01-21 14:12, ASSI via Cygwin wrote: > >> Brian Inglis via Cygwin writes: > >>> Previous maintainer added some artificial single digit release > >>> prefixes (in a few packages), but we decided to drop those and use the > >>> release date directly as used in the package. > > > >> That is the upstream versioning scheme for patch releases or beta > >> versions, which can't be used directly on Cygwin without losing the > >> release part of the package version. > >> You might want to go for something like 6.4+20240120-1 instead. > > I'm not sure that's the right solution > > Ideally, V should be the upstream version label. > > If upstream really is making multiple releases called '6.4', which we're > supposed to distinguish by some other means, then there aren't really > any good answers... > > See the mess that is https://repology.org/project/ncurses/information, > where everyone makes up there own scheme. > > > Good point, but I figured we could add the suffix .1 or something if we > > could not get a change merged upstream: the snapshots are weekly or > > better in ncurses, although others not so often, and I have no idea how > > they decide when to release a new GNU version 6.5? > > > > What happens if we change versioning from 6.4-yyyymmdd to 6.4+yyyymmdd-1? >
for me will make more sense a scheme like 6.4-5+GITID 6.4-6+GITID .. just my 2c€ Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
