Em 30-12-2013 14:10, Mark Hahn escreveu:
> and people start to depend on it, it should be hard to remove it.

Are you referring to some central authority you would have to petition to be allowed to remove? I can't imagine any other process that could be implemented to stop me from removing my module.

In fact that is the essense of Public Licences like MIT

A working solution would be to work like a Version control system: move that module's version to some frozen/not recomended/whatever branch but keep it there because some people may be using it. Either in production or for study only

That is very close to Github's working, which is already the repositoy of choice...

Alain


In other words a computer can't make things harder except maybe to make you type "I want to unpublish this module" a thousand times. And then some clever person might figure out how to script that. :-)


On Mon, Dec 30, 2013 at 4:04 AM, Richard Marr <[email protected] <mailto:[email protected]>> wrote:

    > i'm not disagreeing with you but when you say things like
    "change in behavior" you're sort
    > of sugar coating the fact that packages will fail to install at
    a greater rate than they do now.

    I think the core problem there isn't that removing force-republish
    would encourage greater use of unpublish, it's that npm allows
    anyone to unpublish so easily that it can be done for any reason
    they like... whether for a serious reason (legal issues, malware,
    etc) or on a whim, or drunk, or in a fit of anger over some
    community drama.

    I don't want to go too far down the road of conflating these two
    problems, but I do think it's currently far too easy to unpublish
    modules. If a module has been provided to the community, and
    people start to depend on it, it should be hard to remove it.

    Perhaps it'd be more natural to talk about making unpublishing
    hard before we talk about removing mutability.

    BTW. Thanks Mikael, and everyone else who's contributed to this
    thread. I'm certainly learning new things.

    Rich


    On 23 December 2013 00:36, Mikeal Rogers <[email protected]
    <mailto:[email protected]>> wrote:


        On Dec 20, 2013, at 2:45AM, Richard Marr
        <[email protected] <mailto:[email protected]>> wrote:

        Mikeal,

        To sum up the way I currently see it, switching to immutable
        packages would:

         * solve a whole class of subtle problems caused by
        unrequested code changes

        sure.

         * allow aggressive caching, reducing the cost of the npm
        registry and making npm use faster for most use cases

        this isn't an issue. the cache control can, and must, be
        proactively invalidated on _changes from the database for
        document urls anyway, it's trivial to do the same for tarball
        changes. it can literally cache forever so long as it responds
        to pro-active invlaidation.

         * change behaviour only for version-locked dependencies when
        that (and only that) specific patch is unpublished

        i'm not disagreeing with you but when you say things like
        "change in behavior" you're sort of sugar coating the fact
        that packages will fail to install at a greater rate than they
        do now. this "change in behavior" is not trivial, there is no
        notice sent to someone when their package can no longer
        resolve a dependency, it will usually require someone to see a
        failed install, report an issue, and the maintainer to
        intervene. the only way to avoid this is to never version lock
        your dependencies which we know people don't do and that there
        are tens of thousands of packages in npm today with some
        number of version locked deps.


        That's two HUGE wins, and one downside. The downside can be
        reduced into obscurity being very rare by making it hard to
        unpublish, so that authors only bother to do it if they
        genuinely need to... i.e. serious legal or security
        reasons... cases where it's actually the right thing to do to
        break dependent apps.

        From what I've heard so far, force republish is mainly used
        to keep patch numbers slow and sequential, which seems like a
        much lower priority requirement than introducing behaviour
        changes silently and unexpectedly into dependent apps.

        Please do contribute more if you have more time... I do want
        to understand the root cause of your replies, and please set
        me straight if I've missed or misunderstood any of your comments

        I don't misunderstand you, I don't even think that we disagree
        on what would or would not happen and the potential wins and
        loses. What I don't think we are in alignment about is the
        severity of the up and down sides of the available options.

        We don't get a clean slate. At this point in time we can't
        afford to make changes that might break parts of the existing
        ecosystem even if it makes the future a little better. We can
        only really entertain strategies that make current and future
        packages less prone to these problems without the potential to
        break existing ones.


        Rich




        On 19 December 2013 23:49, Mikeal Rogers
        <[email protected] <mailto:[email protected]>> wrote:

            They won't :)

            Oh well :)

            It's better for things to work than for everyone to agree.

            -Mikeal

            On Dec 19, 2013, at 3:47PM, Alex Kocharin
            <[email protected] <mailto:[email protected]>> wrote:

            Well okay, just one silly argument. How will these
            people know that they're doing the wrong thing if
            nothing will ever break? :)
            20.12.2013, 03:42, "Mikeal Rogers"
            <[email protected] <mailto:[email protected]>>:
            First off, if someone version locks they are already
            doing the wrong thing. Saying "make my package ignore
            bugfix releases" is almost always the wrong thing. In
            this case it's better to keep their package working for
            them since they clearly don't know what they're doing.
            If they **really** didn't want any changes coming in
            that they didn't know about then they had two other
            options that would still work: 1) check the module in
            to git if they are deploying at app or shrinkwrap
            publish if it's not something being deployed 2) stick
            the md5 in package json to ensure nobody can give them
            another tarball for the same version.
            We have to deal with what people are doing in practice
            when they don't necessarily understand the best
            practice and it's especially important when you
            maintain a common dependency to do what you can to keep
            everyone who relies on you working even when they don't
            do things correctly.
            -Mikeal


-- -- Job Board: http://jobs.nodejs.org/
        Posting guidelines:
        https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
        You received this message because you are subscribed to the
        Google
        Groups "nodejs" group.
        To post to this group, send email to [email protected]
        <mailto:[email protected]>
        To unsubscribe from this group, send email to
        [email protected]
        <mailto:[email protected]>
        For more options, visit this group at
        http://groups.google.com/group/nodejs?hl=en?hl=en

        ---
        You received this message because you are subscribed to the
        Google Groups "nodejs" group.
        To unsubscribe from this group and stop receiving emails from
        it, send an email to [email protected]
        <mailto:[email protected]>.
        For more options, visit https://groups.google.com/groups/opt_out.

-- -- Job Board: http://jobs.nodejs.org/
        Posting guidelines:
        https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
        You received this message because you are subscribed to the Google
        Groups "nodejs" group.
        To post to this group, send email to [email protected]
        <mailto:[email protected]>
        To unsubscribe from this group, send email to
        [email protected]
        <mailto:nodejs%[email protected]>
        For more options, visit this group at
        http://groups.google.com/group/nodejs?hl=en?hl=en

        ---
        You received this message because you are subscribed to the
        Google Groups "nodejs" group.
        To unsubscribe from this group and stop receiving emails from
        it, send an email to [email protected]
        <mailto:nodejs%[email protected]>.
        For more options, visit https://groups.google.com/groups/opt_out.




-- Richard Marr -- -- Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to [email protected]
    <mailto:[email protected]>
    To unsubscribe from this group, send email to
    [email protected]
    <mailto:nodejs%[email protected]>
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en

    ---
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to [email protected]
    <mailto:nodejs%[email protected]>.
    For more options, visit https://groups.google.com/groups/opt_out.


--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to