[
https://issues.apache.org/jira/browse/CAMEL-20959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865035#comment-17865035
]
Jiri Ondrusek edited comment on CAMEL-20959 at 7/12/24 8:58 AM:
----------------------------------------------------------------
We can align to Camel versions, it will help navigate users which version is
meant for which Camel version.
But perhaps we would need a smaller granularity, like what if we need to fix a
recipe for migrating to Camel let say 4.7.0. In the time when upgrade-recipes
project was already released for 4.7.0. The new version of recipes should be
something like 4.7.0.1.
On the other hand if we have independent versioning, we can have i.e. 1.0.1
I think that independent versions might present stronger arguments:
- Quarkus-updates is versioned in such way
- hypothetically in the future - we can present a tool (or add some options to
the current CLI tools) to help with migrations. So the tool would hide versions
for the users. (therefore having the same version would not be benefiting us)
- what if we let say with Camel 4.7.2 want to add some recipe for migration to
4.7.3, but the different stream like Camel 4.8.0 is already out. Therefore
camel-recipes 4.8.0 already exists. What would be the release containing
migration to 4.7.3?
I think that having *independent versions* would helps to solve much more
corner cases with recipes (like releasing in different time then Camel, or a
recipe for a special Camel version, ..)
was (Author: jondruse):
We can align to Camel versions, it will help navigate with versions.
But perhaps we would need a smaller granularity, like what if we need to fix a
recipe for migrating to Camel let say 4.7.0. In the time when upgrade-recipes
project was already released for 4.7.0. The new version of recipes should be
something like 4.7.0.1.
On the other had of we have independent versioning, we can have i.e. 1.0.1
I think that independent versions might show stronger arguments:
- Quarkus-updates is versioned in such way
- hypothetically in the future - we can present a tool (or add some options to
the current CLI tools) to help with migrations. So the tool would hide versions
for the users. (therefore having the same version would not benefiting us)
- what if we let say with Camel 4.7.2 want to add some recipe for migration to
4.7.3, but the different stream like Camel 4.8.0 is already out. Therefore
camel-recipes 4.8.0 already exists. What would be the release containing
migration to 4.7.3?
I think that having *independent versions* would helps to solve much more
corner cases with recipes (like releasing in different time then Camel, or a
recipe for a special Camel version, ..)
> Camel-upgrade-recipes: next steps (to enable releasing)
> -------------------------------------------------------
>
> Key: CAMEL-20959
> URL: https://issues.apache.org/jira/browse/CAMEL-20959
> Project: Camel
> Issue Type: Task
> Components: upgrade-recipes
> Reporter: Jiri Ondrusek
> Priority: Major
> Fix For: 4.x
>
>
> TBH I'm not sure what has to be done next.
> [Here|https://github.com/apache/camel-upgrade-recipes/pull/1] is the initial
> commit for the camel-upgrade-recipes repo.
> I think that we should release this library when this commit is merged.
> Why?
> Once released, I can update draft
> [PR|https://github.com/quarkusio/quarkus-updates/pull/177] for
> quarkus-updates project and leverage the camel-upgrade-recipes dependency.
> With some guiding from someone I can try to achieve some of the task.
> (It would be nice to have component in jira, which would represent
> upgrade-recipes.
> The affects version/fix version does not make sense in the camel project, as
> the versioning might be different)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
