sent 00:25:07 02 July 2011, Saturday
by Marc Weber:
> No, seriously: If you're going to break things you should use a "topic"
> branch. If your VCS makes this hard you're using the wrong VCS :)
I see no profit here. I will spend too much time guessing how should I name this
branch instead of doing something. My preoutgoing hooks ensure that nothing will
be pushed unless it passes all tests (though it does not ensure that I won't
change tests themselves), so breakage is not too large.
In any case
1. I am not going to have anything stable at the 'default' branch.
2. Tip is what I use on my machine, so bad breakages will be fixed soon.
3. Never consider SCM version to be stable.
4. 1.-3. are related only to me, not to other developers.
> So "version" will be one of the supported fields for that reason even
> though I'm very unlikely to maintain it myself.
Updating 'version' field, creating tags and posting this to vim.org is easily
scriptable: I do this all in one command. Why don't you want to maintain it?
> I just don't to give this version field a high priority at the
> beginning because it requires visiting each commit.
One of the reasons why I would leave the job of doing a releases on authors:
after creating a series of commits I do
../repository/pkgdo.pl release fooplugin +++ $'Added foo#Bar()\nFixed...'
`+++' is incrementing plugin version (in this case: third number). $'...' is
comment to release.
Where are you going to get comments on releases if you do release automatically?
What if repository is very large (because somebody is trying to perform a DoS
attack)?
> If your code is still unstable users will tell you and you'll reach a
> new stable state much faster.
Code is stable enough in releases. Users must not expect development version to
be stable. Vim.org must not do this either.
> preferred: true # for your style of development. Indicates whether the
> latest stable version should be used
Understood nothing here. Who is using the latests stable version?
> > No, it is not. I don't trust this and relations are defined by tags.
>
> Of course you neither trust any VimL code unless you've written it
> yourself. But hey, don't you think that this will give you an idea about
> what could be important? Nobody prevents you from verifying the
> statements yourself.
>
> And of course I'd rather propagate "join and improve existing projects"
> rather than "fork and tell everybody your code is better" even though it
> may not.
>
> So this is meant to place hints at "unmaintained" projects so that you
> can get users attention. Of course the user still has to decide what to
> install and use.
Deprecations and support dropped by maintainer is a property of an old plugin,
not of a new. What are these fields for? User can read about it in project
description and VAM cannot do anything automatically when somebody said `my
plugin superseeds foo' because this information is untrusted.
> Eg visit this: http://www.vim.org/scripts/script.php?script_id=2540
> The first impression says: "Hey, great plugin". Then you fix something.
> Then you sent a patch. Then you don't get a reply. Then on irc you're
> told: upstream is at github.com/garbas/... Then you can rewrite your
> patch cause all the code has changed?
> What is left ? A bad feeling about wasted time on all sides.
I don't argue the fact that there should be fields `project page' and/or `SCM
repository'.
By the way, where are fields `projectPage' and `issueTracker'? If you are going
to pull data from addon-info.json, they should be there also.
Original message:
> Excerpts from ZyX's message of Fri Jul 01 20:54:04 +0200 2011:
> > > That's not an issue. We could introduce a version field in
> > > addon-info.txt.
> >
> > For me it is fine.
>
> No, seriously: If you're going to break things you should use a "topic"
> branch. If your VCS makes this hard you're using the wrong VCS :)
>
> But I agree that it should not me forcing working styles on others.
> So "version" will be one of the supported fields for that reason even
> though I'm very unlikely to maintain it myself.
> Thus I'd also suggest a setting which tells whether the latest stable
> version should be preferred.
> I just don't to give this version field a high priority at the
> beginning because it requires visiting each commit.
>
> If your code is still unstable users will tell you and you'll reach a
> new stable state much faster.
>
> fields I'd use in addon-info.txt:
>
> tags: ["C++",".."] # to group plugins by language, feature, ...
> name: # name used to resolve dependencies. If there are multiple matches
> ask user which one to use # if there are obvious reasons to prefer one
> # vim-addon-manager-known-repositories will reflect this in some
> # way
> dependencies: {
> # VAM style list of dependencies by name
> }
> maintainer : "email"
>
> version: "0.3" # if this changes assume new stable version
> preferred: true # for your style of development. Indicates whether the
> latest stable version should be used
>
> relations: ... relations to other plugins.
>
> > No, it is not. I don't trust this and relations are defined by tags.
>
> Of course you neither trust any VimL code unless you've written it
> yourself. But hey, don't you think that this will give you an idea about
> what could be important? Nobody prevents you from verifying the
> statements yourself.
>
> And of course I'd rather propagate "join and improve existing projects"
> rather than "fork and tell everybody your code is better" even though it
> may not.
>
> So this is meant to place hints at "unmaintained" projects so that you
> can get users attention. Of course the user still has to decide what to
> install and use.
>
> Eg visit this: http://www.vim.org/scripts/script.php?script_id=2540
> The first impression says: "Hey, great plugin". Then you fix something.
> Then you sent a patch. Then you don't get a reply. Then on irc you're
> told: upstream is at github.com/garbas/... Then you can rewrite your
> patch cause all the code has changed?
> What is left ? A bad feeling about wasted time on all sides.
>
> Its ok to have different ideas about how things should be.
> I'd like to introduce a soft force that those differences get documented
> and pointed out. That's the idea.
>
> Marc Weber
No comments:
Post a Comment