I can only encourage you to keep track of the most significant changes
in your package in its NEWS file, especially if its history is a little
bit complicated as it seems to be the case here. Briefly explaining the
motivations behind those changes is a good idea.
Cheers,
H.
On 06/11/2018 08:47
OK...1.98.0 and 1.99.0 sounds good. Shall do that.
Is it necessary to convey the reasons for the change e.g. NEWS file ?
That's my last question...I hope !
On Tuesday, June 12, 2018, Hervé Pagès wrote:
> Ah ok. Yes 1.99.0 is fine. Then the package will be released as 2.0.0
> in Fall as part of
Ah ok. Yes 1.99.0 is fine. Then the package will be released as 2.0.0
in Fall as part of BioC 3.8.
Not that version numbers have a strong meaning but I was thinking that
maybe you could bump to 1.98.0 in release to sort of indicate the fact
that the package in release is the precursor of what's g
Thanks, I shall do that. Its OK to keep the master as 1.99.0 ? It should
probably have been 1.19.1 ?
On Monday, June 11, 2018, Hervé Pagès wrote:
> Hi,
>
> Having a package that is known to be broken in release is not
> really an option.
>
> How about replacing all the files in the RELEASE_3_7
Hi,
Having a package that is known to be broken in release is not
really an option.
How about replacing all the files in the RELEASE_3_7 branch
with what's in the master branch. For the version, just bump
z (in x.y.z) to its next version. Don't touch x or y. So the
version would become 1.18.1 in
Hi Samsiddhi,
Yes, you can do that. Make sure to bump the version even in the RELEASE_3_7
branch if you decide to take that option.
Best,
Nitesh
P.S: I’m moving this thread to bioc-devel because it’s useful to the community.
> On Jun 5, 2018, at 11:59 AM, Samsiddhi Bhattacharjee wrote:
