What is difference between published and public methods / attributes?

According to Martin Fowler "Something can be public but that does not mean you have published it." Does this mean something like this:

public interface IRollsRoyceEngine
{
    void Start();
    void Stop();
    String GenerateEngineReport();
}

public class RollsRoyceEngine : IRollsRoyceEngine
{
    public bool EngineHasStarted { get; internal set; }

    public bool EngineIsServiceable { get; internal set; }

    #region Implementation of IRollsRoyceEngine

    public void Start()
    {
        if (EngineCanBeStarted())
            EngineHasStarted = true;
        else
            throw new InvalidOperationException("Engine can not be started at this time!");
    }

    public void Stop()
    {
        if (EngineCanBeStopped())
            EngineHasStarted = false;
        else
            throw new InvalidOperationException("Engine can not be started at this time!");
    }

    public string GenerateEngineReport()
    {
        CheckEngineStatus();
        return EngineIsServiceable ? "Engine is fine for now" : "Hmm...there may be some problem with the engine";
    }

    #endregion

    #region Non published methods

    public bool EngineCanBeStarted()
    {
        return EngineIsServiceable ? true : false;
    }

    public bool EngineCanBeStopped()
    {
        return EngineIsServiceable ? true : false;
    }

    public void CheckEngineStatus()
    {
        EngineIsServiceable = true;
        //_EngineStatus = false;
    }

    #endregion

}

Can it be said that published interface of this is IRollsRoyceEngine not whatever is in RollsRoyceEngine?

If so what is the real difference between public and published methods?

From stackoverflow

• I assume he means that the contract is king - just because a method in your class is public, doesn't entitle clients to assume that they can call it, or that they know what it does, or that it will be there in the next version. APIs are not defined by the source, they're defined by a contract, usually in the form of documentation.

  It is the responsibility of the client not to call undocumented (unpublished) functions, not the responsibility of the implementer to hide methods which shouldn't be called.

  Some people might disagree with this - typically those who don't trust documentation, and would rather find out how things work by looking at the source to see what it actually does, rather that what the author claims it does. They may well have a point, especially in practice when dealing with under-documented code. But I think that's in opposition to what Fowler is saying, which is that functionality should be formally defined, rather than inferred by examination of the particular implementation.

  Prajwal Tuladhar : More can be found about this issue at http://martinfowler.com/ieeeSoftware/published.pdf

• In my opinion mentioned white paper talks about target audience of the API rather than the distinction between interface and its implementation.

  You can find analogy in Framework Design Guidelines which says that once your API shipped you have a contract with consumers. For example, if you shipped in v1 of your framework IService interface you cannot change it in v2 because it will introduce breaking changes to end developers. Instead you must create new interface IService2 inhereted from IService and ship it with v2.

  So basically public API becomes published once you "sign a contract" with end developers.

  Returning back to your code - it will be published when you ship it to development community for example.

  Hope this explanation will help.