On Mon, 2017-03-20 at 10:35 -0400, Jon Moore wrote: > If we've been using semantic versioning, I'd hesitate to move away > from > that; it sets important expectations with the user community. > > If the main issue we're facing is the release management overhead of > alpha/beta/GA on Oleg, perhaps we should try to recruit a release > manager > on the dev list? I could also ask around at work to see if there's > someone > who might want to take that on, if folks would like me to. > > Jon
Hi Jon It would be nice to have some extra hands helping with the release management but it is just not practical without being a committer on the project and being fairly familiar with ASF release processes and requirements. I do not mind doing all the release management work by myself but I hate policing other committers. As long as we all agree (through a lazy consensus or by way of a formal vote) that we want to continue following the semantic versioning and we generally avoid making API visible changes in maintenance releases I guess I will be fine. Cheers Oleg PS: migration to Git would help a great deal. > > On Sun, Mar 19, 2017 at 9:07 AM, Gary Gregory <[email protected] > > > wrote: > > > On Mar 19, 2017 1:38 PM, "Oleg Kalnichevski" <[email protected]> > > wrote: > > > > On Sun, 2017-03-19 at 08:55 +0100, Gary Gregory wrote: > > > Hi All, > > > > > > - Do we have any idea of our user's expectations? Is HC knows for > > > adhering > > > to Semantic Versioning? Have we done so in the past? > > > > > > > We have been using Semantic Versioning since HC 4.0. > > > > > > > - Why not just make the version numbers evolve following what the > > > code > > > does? If we add new APIs and we are backward compatible, then > > > that > > > can be a > > > minor release 4.5.x -> 4.6.0 for example. If we do that very > > > often, > > > then we > > > can end up with versions like 4.15.0 and that's fine. We can > > > avoid > > > wringing > > > our hands when we want a maintenance version like a 4.5.3 -> > > > 4.5.4 to > > > contain new APIs. > > > > > > - Are there hidden costs to releasing minor releases as opposed > > > to > > > maintenance releases? Right now, we use branches it seems. We can > > > keep > > > doing that or just have a 4.x branch until we need another > > > specific > > > 4.x.y > > > branch. > > > > > > > The only difference between a minor release and a maintenance > > release > > is that a minor release should have alpha and beta phases in order > > to > > allow for users feedback. If we skip alpha and beta phases, there > > is > > really no difference. > > > > > > Strictly speaking it seems like we know we should cut a new minor > > release > > for what I recently did and perhaps this Windows related security > > stuff. > > > > Pragmatically, it seems like this is just more work for you and we > > should > > give you wiggle room to avoid extra hoops to keep getting our wares > > out ;-) > > > > Gary > > > > > > Oleg > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
