How often should downstreamers update?

[aus9]

@Juanito

I know I could do this by pm but it might be useful for other downstreamers to get an idea too?

As luck would have it, one of my packages updated shortly after I submitted an update on TC64. Going back over a year....it appears to have about 3-4 releases. The changelog for each package could indicate the update is a security update so thats a no brainer.

But if the changelog indicates only a feature update.....how often would you prefer updates to the repo?

I ask this because I am aware that you maintain TC32 TC64 RPi images and their repos, and answer a lot of questions from members like me etc So I can not imagine how you manage your time, but would like a guide line please.

I am aware not to reveal private conversations without mutual consent but the package I am alluding to, or in general is not a massive upstream download..if you know what I mean. And if it was a massive one, I am sure members would advise you first before attempting frequent submission updates.

thanks for reading

[Juanito]

I think it is difficult to generalise - some mature apps change very little over time, some new apps change significantly in a short period of time and some apps change their abi with almost every update and thus break apps that reply on them.

[Sashank999]

Just like we have provides.db.gz, we could have tree files of all tczs in the repo compressed into trees.tcz.gz or somehing like that so that we can find all the dependencies of each tcz and hence update the tcz so that it doesn't break other.

This also helps to solve some of the tce-unload problem.

[aus9]

Ok how about a different guideline if you care to reply.

for any random software,
where the update is a security update -> update
where the downstreamer thinks a lot of members might use it or find it useful.....update every 6 months
(aterm would be an example of high use) (sway would be an example of low use IMHO)
otherwise leave it to a major update of significance (I have seen both replies that some updates break others)
otherwise leave to once a year.

BTW the secret software I was thinking of updating was sway. But I am happy to run it as a private update with a deleted md5 so Apps does not think there is an update. AFAIK Apps does not check the version number -> only the change in md5sum. But I was still interested in a general guideline.

Thanks

[Juanito]

Just like we have provides.db.gz, we could have tree files of all tczs in the repo compressed into trees.tcz.gz or somehing like that so that we can find all the dependencies of each tcz and hence update the tcz so that it doesn't break other.

The tree file does not necessarily help with recursive deps.

Where A depends on B, which depends on C, you do not know if A depends on C or not.

[Juanito]

for any random software,
where the update is a security update -> update
where the downstreamer thinks a lot of members might use it or find it useful.....update every 6 months
(aterm would be an example of high use) (sway would be an example of low use IMHO)
otherwise leave it to a major update of significance (I have seen both replies that some updates break others)
otherwise leave to once a year.

seems reasonable...

[Sashank999]

The tree file does not necessarily help with recursive deps.
Where A depends on B, which depends on C, you do not know if A depends on C or not.

What about pc files ?
We have pkg-config files for many packages in the repo. The .pc files can be very helpful. If the .pc files said to include the C(the said C in the example above) software's flags, then we could confirm that it also requires C. Combining this with tree.gz we could something useful (IMHO and sorry if my method looks awkward).