On Wed, Dec 6, 2023 at 7:45 PM Emond Papegaaij <emond.papega...@gmail.com> wrote:
> Op wo 6 dec 2023 18:22 schreef Richard Eckart de Castilho <r...@apache.org > >: > > > > We can switch from LastModifiedResourceVersion to something else in our > > > applications to work around this issue, but maybe we should consider > > > tracking down this issue and release a 9.16.1. I'd expect we are not > the > > > only ones using LastModifiedResourceVersion. > > > > I wonder how this is supposed to work at all... > > > > AFAIK git does not track the last modification date - so I guess that > date > > would reflect whatever the modification date is on the machine of the > > developer that does the release...? > > > > I'm not sure either, but using the last modification date of a local > https://github.com/apache/wicket/blob/a68536eb095bb5cf59e4063b6af9436523ddc623/wicket-core/src/main/java/org/apache/wicket/settings/ResourceSettings.java#L650-L664 LastModifiedResourceVersion is used in DEV mode by default. MessageDigestResourceVersion is for PROD. > checkout would be better than using no timestamp at all. For this part of > the code, it's not a big problem if the modification date is set to a later > date than what it actually is. It might cause some cached files to be sent > anyway when in fact the file did not change. The current situation causes > files to not be sent when they really should be. Actually it would be fine > if the modification date was set to the current timestamp during the > release. > > Best regards, > Emond > > > >
