You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tamas Cservenak (Jira)" <ji...@apache.org> on 2024/02/16 09:53:00 UTC

[jira] [Updated] (MNG-8055) Investigate possible solutions for build number diffs on deploy

     [ https://issues.apache.org/jira/browse/MNG-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tamas Cservenak updated MNG-8055:
---------------------------------
    Fix Version/s: 3.9.7
                       (was: 4.0.0)
                       (was: 4.0.0-alpha-13)

> Investigate possible solutions for build number diffs on deploy
> ---------------------------------------------------------------
>
>                 Key: MNG-8055
>                 URL: https://issues.apache.org/jira/browse/MNG-8055
>             Project: Maven
>          Issue Type: Task
>          Components: Artifacts and Repositories
>            Reporter: Tamas Cservenak
>            Priority: Major
>             Fix For: 3.9.7
>
>
> The "snapshot freeze" is a common practice during development: simply use a timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one to "freeze" given snapshot deploy.
> This works for simple cases (one dependency, or "aligned" reactor).
> But take a look at Resolver itself: it has new-old and added-gone-readded modules, and their build numbers are different.
> Problem is, that while timestamp is _same_ (deduced from session start), the build number is determined from remote repository (deploy target) state.
> This makes "snapshot lock down" impossible on long(er) running projects, like Resolver itself is.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)