Up API version for 4.0 release

Created by: riyad

Created by: dzaporozhets

we should switch to using project id only. Code is no longer exist. Path is not a reliable option without namespace

By Administrator on 2012-12-20T19:18:41 (imported from GitLab)

Created by: riyad

Good idea.

By Administrator on 2012-12-20T19:20:27 (imported from GitLab)

Created by: riyad

@randx can you have a look at the v4.0-api-fixes branch?

By Administrator on 2012-12-21T18:00:51 (imported from GitLab)

Created by: dzaporozhets

@Riyad good one. Can you make PR? I'd like to have it in v4.0

By Administrator on 2012-12-21T21:27:58 (imported from GitLab)

Created by: yangchenyun

@Riyad I suggest subsitute codename with :path instead of removing it simply.

As the :id of a project is only used internally by gitlab, while in fact the :path is what gitlab communicates with external services(https, or git) There is no way for external services to know the :id of an project without consulting gitlab first, which makes this API less usable.

For example, the :path (or previous codename) is maintained in each git repository at .git/config, script could read from that and query about the project info at gitlab directly. Without the :path on the API, script needs to query gitlab about the :id of the project and send the query about the project with the :id. The process in API V3 is more complex than in API V2.

As the upgrade in 3.1 added the :path to the project instead of the codename, I suggest add the :path to the API to identify projects.

By Administrator on 2012-12-22T00:21:08 (imported from GitLab)

Created by: riyad

@randx @vsizov I think the project path in the API should map to path_with_namespace from the Model, don't you think?

By Administrator on 2012-12-22T14:29:00 (imported from GitLab)

Created by: riyad

It may also be useful to make it read-only.

By Administrator on 2012-12-22T14:29:11 (imported from GitLab)

Created by: dzaporozhets

@Riyad yes it might be a good idea. But lets leave it as is for 4.0

By Administrator on 2012-12-22T14:42:52 (imported from GitLab)

Created by: riyad

But it would break API compat afterwards. :(

By Administrator on 2012-12-22T14:46:25 (imported from GitLab)

Created by: dzaporozhets

we already did it. We removed code. Path we cannot use because of namespaces.

By Administrator on 2012-12-22T15:13:22 (imported from GitLab)

Created by: riyad

But the path parameter as it is right now is useless.

By Administrator on 2012-12-22T15:56:59 (imported from GitLab)

Created by: riyad

Only if it also has the namespace it makes sense.

By Administrator on 2012-12-22T15:57:42 (imported from GitLab)

Created by: dzaporozhets

its a directory name. Namespace can be changed (moved to group etc) but directory name is constant

By Administrator on 2012-12-22T15:58:37 (imported from GitLab)

Created by: riyad

But it's not useful for anything at the moment. If you have path as it is right now, you can't use it to construct the url or use it as an identifier, because the namespace information is missing.

By Administrator on 2012-12-22T16:01:19 (imported from GitLab)

Created by: dzaporozhets

yeap. lets remove path from api response then

By Administrator on 2012-12-22T16:02:57 (imported from GitLab)

Created by: riyad

We can add it back later if we have a proper solution, maybe together with an API for Groups.

By Administrator on 2012-12-22T16:04:38 (imported from GitLab)

Created by: riyad

Or just add expose :path_with_namespace, as: :path to https://github.com/gitlabhq/gitlabhq/blob/master/lib/api/entities.rb#L20

By Administrator on 2012-12-22T16:05:56 (imported from GitLab)

Created by: dzaporozhets

I afraid of confusion. Better remove it

By Administrator on 2012-12-22T17:02:41 (imported from GitLab)

Created by: dzaporozhets

And maybe we need to add something instead like project url or something.

By Administrator on 2012-12-22T17:05:07 (imported from GitLab)

Created by: riyad

ok

By Administrator on 2012-12-22T17:24:21 (imported from GitLab)