Re: [cbi-dev] Conventions for repository URLs

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

FYI, this is what we do to manage m2e p2 repositories and corresponding tags


http://wiki.eclipse.org/M2E_updatesite_and_gittags

--
Regards,
Igor

On 12-04-04 11:47 AM, Mickael Istria wrote:
> Hi all,
>
> A topic that should be part of the discussions about CBI (which as far
> as I remember was not covered during the EclipseCon meeting) is to set
> up conventions for update-sites URL.
> Currently, there are as many conventions as there are projects, some
> re-use the name of release train in repo, some use their own versioning,
> some use a single static URL and update its content... We should try to
> find the list of requirements for consumers and then find out some
> conventions that would work for all.
>
> Generally, a project maintain have to maintain several repositories:
> * N releases repositories (1 for each release)
> * 1 snapshot repository for each branch/development stream for testing
> * 1 repository for milestones (to be used by release train)
>
> Here are some ideas on what comes to end-user mind when trying to find
> the right repository for their work:
> * Being able to find any release of the project
> * Being able to find which version will work for release train X
> * Being able to find the latest version
> * Being able to get latest snapshot build for each branch
> * Being able to get latest milestone for release train
> Also I think it would make sense to have content being located at a
> single location, and then to use symlinks and symbolic URLs.
>
> I personally like URL containing explicitly the version of the project,
> and that tell whether it is a release of a snapshot.
> For example
> http://download.eclipse.org/modeling/gmf/tooling/3.0/snapshot
> http://download.eclipse.org/modeling/gmf/tooling/2.4/release
> http://download.eclipse.org/modeling/gmf/tooling/2.4.1/snapshot
> http://download.eclipse.org/modeling/gmf/tooling/2.4.1/milestone
> http://download.eclipse.org/modeling/gmf/tooling/2.4.1/juno (links to
> /milestone, and when ready, links to /release)
> And then using symlink to tag 2.4/release as "Juno" could be cool. So
> Juno only references the "tag" and project can move to a newer release
> when ready.
>
> With such an approach:
> * Builds would follow a promotion process (first they are snapshots,
> then they are promoted to milestone, then to release) using simple cp.
> * when a release happens, it does not make sense to keep /snapshot or
> /milestone.
>
> Here is some food for thoughts ;)
> Cheers,
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev