Thanks,

I think it is a good initiative. since mie4j is a library, and a lower
level one, we can announce the change intention on the mailing list.

After that, when changes are ready to release, we can issue a series of
1-2 Release Candidates and give people a chance to test them out and
provide some feedback.

If no feedback comes in a defined period of time: 1-2 weeks we can make
the release.

Regards,

Eugen

La 16.05.2020 09:21, David Leangen a scris:
> Hi,
>
> I made a PR as promised:
>
>   —> https://github.com/apache/james-mime4j/pull/31
>
> As I commented in the PR:
>
>> Based on my simplistic analysis, is was not very difficult to separate what 
>> appears ought to be "public" from what ought to be "private".
>>
>> The main advantage of separating public packages (API) from private packages 
>> (implementation) is that it decreases the surface area of the API. It makes 
>> versioning much simpler, provided that the API was well designed. It also 
>> helps keep users out of trouble, as what they should be using and what they 
>> shouldn't be doing is more obvious.
>>
>> Used together with semantic versioning makes it much easier to provide 
>> releases and a nice upgrade path for users.
>>
>> I cannot comment on the design quality of the API itself because I have not 
>> yet used it. It does appear to me, however, that there are many classes that 
>> would be best not to expose to users of the library.
>>
>> This would of course be a major, breaking change. However, it is also just a 
>> refactoring (change of package and, ideally, ceasing to directly instantiate 
>> classes that reside in "private" packages), so it's not really all that bad.
>>
>> My suggestion would be to version this as 0.9.0. Once it is confirmed to be 
>> "stable", then it ought to be released as version 1.0.0, according to 
>> semantic versioning guidelines.
>>
>> If this idea is acceptable to the community, then I could investigate how to 
>> make this work both within and outside of an OSGi framework, and could also 
>> investigate the other modules.
>>
>> If this idea is not well received, I can easily drop it. I am only 
>> suggesting to try to be helpful, not because I really need this. :-)
> Cheers,
> =David
>
>

Reply via email to