This is against apache rules! We MUST vote on a release, not check it in our own repository. You can label the version 3.0-alpha1 for example. Please remove these binaries ASAP and start a release VOTE instead.
Gary On Thu, Aug 24, 2023, 12:44 PM Joseph Kesselman <kesh...@alum.mit.edu> wrote: > Mutual, I'm afraid I think you're wrong on this one. There are appropriate > ways to share early/alpha prebuilds. Checking them into the source > repository is not a good one. > > -- > /_ Joe Kesselman (he/him/his) > -/ _) My Alexa skill for New Music/New Sounds fans: > / https://www.amazon.com/dp/B09WJ3H657/ > > () Plaintext Ribbon Campaign > /\ Stamp out HTML mail! > ------------------------------ > *From:* Mukul Gandhi <muk...@apache.org> > *Sent:* Thursday, August 24, 2023 11:32:29 AM > *To:* dev@xalan.apache.org <dev@xalan.apache.org> > *Subject:* Re: XalanJ XSLT 3.0 experimental developer build > > Hi Vladimir, > Thanks for the thoughts. > > On Thu, Aug 24, 2023 at 8:23 PM Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> wrote: > > > What is the point of commiting binaries to source control? > > > > Binaries make it harder to review source provenance, and they make git > slower as it transfers more data. > > > > Please consider other options like publishing snaphots to > repository.apache.org for preview purposes. > > Your points mentioned within your mail above, may be somewhat correct > from ASF process point of view. But I think that, ASF should be > allowing their teams to take such decisions independently. > > There are other Java binary jar files currently available within > XalanJ repos 'tools' and 'lib' folders. With that sense, this > committed zip archive having XalanJ related jar files, should be ok I > believe. When we shall make an actual XalanJ next release, we could > delete the zip archive > xalan-j_xslt3.0_developer_binaries_2023-08-24.zip from its present > location. This zip archive is committed, assuming not to be > permanently available for future at this location. > > Apart from you, there may be other users from XalanJ forum, and XSLT > community in general, who may find such sharing of XalanJ developer > builds useful. > > IMHO, your comments so far within this thread, are not helpful to > share progress by XalanJ developers to XalanJ community. Instead of > only commenting wrt XalanJ process related issues it shall be more > helpful if you may contribute real XalanJ codebases, fixes, test cases > (there are still, various gaps between XalanJ XSLT 3.0 and XPath 3.1 > implementations on repos xalan-java's branch xalan-j_xslt3.0, and the > standards coverage required by these specs. more XalanJ active > developers who could contribute code and test cases, shall definitely > be helpful) etc that enhances the XalanJ XSLT 3.0 and XPath 3.1 > functional implementations. > > > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org > For additional commands, e-mail: dev-h...@xalan.apache.org > > >
