Autofixture: Discusión: El prefijo del espacio de nombres 'Ploeh'

Creado en 2 abr. 2017  ·  32Comentarios  ·  Fuente: AutoFixture/AutoFixture

Al abrir este boleto, quiero comprender nuestra posición con respecto al espacio de nombres 'Ploeh.AutoFixture' que tenemos actualmente en AutoFixture y cuál es nuestra visión al respecto en el futuro. Esta pregunta ya surgió y definitivamente la volveremos a encontrar en el futuro :)

Hay 2 formas en que podríamos comportarnos: mantenerlo como está o eliminar el prefijo Ploeh . Cada opción tiene sus pros y sus contras.

Mantener como está

La idea es mantener el prefijo Ploeh en todos los espacios de nombres por ahora, a pesar de que Mark ya no es el propietario del repositorio.

__Pros: __

  1. Eso inmortalizará las inversiones de
  2. Eso no creará cambios importantes durante la migración a v4 .

__Contras:__

  1. Propiedad muy poco clara. Como Mark dijo aquí , mucha gente todavía piensa que él es el propietario del repositorio. Si mantenemos el prefijo del espacio de nombres, esta confusión seguirá presente.
    Por otro lado, si lo eliminamos, su nombre no estará más presente en todos los espacios de nombres importados, por lo que después de un tiempo la confusión desaparecerá.
  1. Confusión de los consumidores. Se parece al punto 1, pero la diferencia es que no todo el mundo sabe quién es el Ploeh . Puede que los consumidores nuevos (y existentes) no tengan claro por qué tenemos este prefijo inusual :)

Cambiar el prefijo

La opción es alterar todos los archivos en todos los proyectos y eliminar el prefijo Ploeh . Técnicamente, es fácil de hacer, por lo que la pregunta es solo sobre nuestra decisión.

Los pros y los contras son los mismos que para la opción _Mantener como está_:

__Pros: __

  1. Propiedad. Quedará claro que AutoFixture es una organización independiente que gestiona el proyecto por sí misma. The Mark (Ploeh) no lidera más el proyecto. Además, menos gente pensará que este proyecto pertenece a Mark.
  1. Espacio de nombres simplificado. Eso eliminará las palabras innecesarias del espacio de nombres, por lo que las importaciones de espacios de nombres serán menos detalladas.

__Contras:__

  1. Este será un gran cambio rotundo ya que todos los que migren a v4 se verán obligados a cambiar las importaciones de espacios de nombres. Además, podría suceder que los nombres de tipos completos estén codificados en algún lugar como cadenas. Por supuesto, se hará solo una vez y es fácil de hacer, pero hay personas que no hacen un seguimiento de todas estas cosas de propiedad y solo usan el AF; será bastante aburrido para ellos.

En primer lugar, me gustaría escuchar la opinión de @ploeh sobre este cambio y de qué manera él personalmente prefiere. Tú, Mark, has invertido mucho aquí, así que tu visión sí importa.

También me gustaría involucrar a los chicos del equipo principal: @ecampidoglio , @moodmosaic y @adamchester.

Después de que decidamos, tendremos un problema con nuestra decisión, por lo que más tarde podríamos reenviar a cualquiera que pregunte / no esté de acuerdo aquí :)

question

Comentario más útil

parece desagradecido con respecto a Mark.

No se preocupe por eso. El mejor agradecimiento que me puede dar es mantener vivo AutoFixture. Si puede hacer eso, he logrado crear algo que sea viable por derecho propio. Pocas cosas pueden ser más satisfactorias que eso.

Todos 32 comentarios

Que yo sepa, la gran mayoría de los proyectos de OSS tienen el espacio de nombres raíz idéntico al nombre, por lo que no veo ningún problema aquí. Dado que este sería un cambio importante, solo necesita incrementar la versión principal.

👍 para cambiar el espacio de nombres raíz a AutoFixture en una versión de última hora.

No me importa mantener el espacio de nombres Ploeh. La propiedad no se relaciona y
cambios de espacio de nombres en cosas que funcionan perfectamente, ¿por qué ...?

El domingo 2 de abril de 2017 a las 14:04, Adam Ralph [email protected] escribió:

👍 para cambiar el espacio de nombres raíz a AutoFixture en una versión de última hora.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

Estoy de acuerdo con el análisis general (los pros y los contras descritos anteriormente).

Como ya han señalado varias personas aquí, cambiar el espacio de nombres sería un cambio rotundo. OTOH, cambiar el espacio de nombres entre la versión 3 y la versión 4 parece al menos defendible, debido al cambio en la gobernanza. Sería mucho más difícil defender la eliminación de 'Ploeh' entre la versión 4 y la versión 5.

Si desea eliminar 'Ploeh' del espacio de nombres, ahora es el momento de hacerlo.

@ploeh Gracias por la respuesta. Una pregunta más para usted: ¿qué opción prefiere personalmente? :) Sé que esta es una pregunta un poco complicada, pero creo que no soy el único para quien importa, ya que eres un fundador (o cofundador, no estoy seguro: enrojecido :).

Prefiero que tomes la decisión que crees que es la mejor para que el proyecto avance 😉

Desde una perspectiva externa, puedo decir que tener el espacio Ploeh.Autofixture nombres

Es una especie de sorpresa escribir using Auto... y recibir una lista vacía de Intellisense.

Estoy de acuerdo con @Kralizek.
Pero el problema de cambiar el nombre del proyecto a Fixture.Net (a pesar de que personalmente apoyaría este paso) significaría romper con bastante amplio y conocido en el nombre de la comunidad .NET.

De acuerdo con lo que escribió @ploeh

Si desea eliminar 'Ploeh' del espacio de nombres, ahora es el momento de hacerlo.

Por supuesto, esto solo puede suceder en la rama v4 .

Un cambio de espacio de nombres es bastante fácil, busque y reemplace y lo hace en su propio código fuente.

El problema es con nuget si otros paquetes están usando AutoFixture y no tienen el delimitador de versión correcto en el nuspec, entonces esto también se romperá. Pero por el momento, el usuario puede volver fácilmente a AutoFixture 3.x. Esto se puede abordar en la documentación, publicación del blog de lanzamiento o lo que sea.

Estoy a favor de eliminar a Ploeh del espacio de nombres, nunca me gustarían nombres personales en el espacio de nombres, hice esto al principio de mis proyectos, me odié por hacer eso;)

si otros paquetes están usando AutoFixture y no tienen el delimitador de versión correcto en el nuspec, esto también se romperá

Yo no me preocuparía por eso. El mismo problema existe para todas las versiones de última generación. Si los paquetes posteriores han optado por no poner un límite superior exclusivo en la próxima versión principal, por ejemplo, <dependency id="AutoFixture" version="[3.0,4.0)" /> , entonces están invitando a este problema cada vez que se lanza una versión principal de AutoFixture.

@abatishchev ¿ Fixture.Net proviene de otra discusión? Estaría muy feliz simplemente cambiando el espacio de nombres a AutoFixture

@moodmosaic ¿Podrías también agregar tu posición sobre esto? Creo que necesitamos tener las opiniones de todos los mantenedores centrales para tomar la decisión final.

Ι ya lo hice .

@moodmosaic Vi esa respuesta, pero no estoy seguro de haber

Yo voto por mantenerlo. Menos disruptivo.

¿Por qué te preocupa hacer cosas disruptivas? Mucha gente pide este cambio.
Incluso menos perturbador sería dejar el proyecto como está, sin hacer ningún cambio. Pero de eso no se trata todo este proceso, ¿no es así?
Personalmente, me gustaría que siguiera adelante con este cambio.

@moodmosaic Vi esa respuesta, pero no estoy seguro de haber entendido tu posición.

Estaría bien por mí, si el espacio de nombres raíz cambia de nombre a solo AutoFixture en v4 .

Si bien mantengo mi voto anterior para mantener el espacio Ploeh nombres

Dado el cambio de propiedad, veo cómo tendría sentido que el proyecto siga adelante y es el momento adecuado. En este punto, los únicos contraargumentos que se me ocurren se basan únicamente en las emociones.

@ecampidoglio , yo también estaba teniendo emociones, pero creo que es más 'correcto' con solo _AutoFixture_ en v4 ...

@moodmosaic Gracias por la respuesta, a mí me pasa lo mismo. Cuanto más aprendo este proyecto, más veo y me doy cuenta de la cantidad de trabajo que Mark hizo aquí: una gran cantidad de discusiones diferentes, pequeños ajustes, respuestas sobre SO, etc. Se vuelve cada vez más difícil tomar la decisión de recortar el prefijo. parece desagradecido con respecto a Mark.

Por otro lado, entiendo que el simple prefijo AutoFixture se verá mucho mejor y consistente. De hecho, no hay nada horrible aquí, ya que el nombre de Mark seguirá estando presente en la lista de autores del paquete, wiki, problemas ... Con @adamchester y @ecampidoglio vota para mantener el prefijo, se vuelve aún más difícil tomar la decisión - mucho lo emocional está presente aquí. Probablemente, deberíamos separar el aspecto emocional y no mezclar las cosas. Personalmente, no trato el recorte del espacio de nombres como un acto de depreciación del trabajo de Mark; para mí, la razón es pura tarea doméstica. Todavía le estaré muy agradecido incluso si el prefijo no está.

Sin embargo, dado que comencé a trabajar en el proyecto demasiado tarde (y nadie me conoce), siento que no puedo entender completamente la contribución de Mark y, por lo tanto, la última palabra definitivamente debería quedar en manos de los colaboradores principales.

@zvirja Creo que mi comentario anterior :

Estoy de acuerdo con que se elimine si eso es lo que la mayoría de la gente quiere.

Entonces, sí, prefiero mantenerlo, pero estoy de acuerdo con el espacio de nombres AutoFixture en v4. 😉

Mi opinión es básicamente la misma que la de @ecampidoglio : prefiero mantener el espacio de nombres como está solo para evitar interrupciones innecesarias a los usuarios, pero estoy de acuerdo con cambiarlo a solo AutoFixture en v4.

parece desagradecido con respecto a Mark.

No se preocupe por eso. El mejor agradecimiento que me puede dar es mantener vivo AutoFixture. Si puede hacer eso, he logrado crear algo que sea viable por derecho propio. Pocas cosas pueden ser más satisfactorias que eso.

¡Gracias por la respuesta, Mark!

Dadas todas las respuestas anteriores y dado que al equipo central no le importa cambiar el espacio de nombres, agregaré esto al alcance v4.

Hay una cosa más que pasé por alto para preguntar: los nombres de las asambleas. Parece que actualmente los nombres de ensamblados también comienzan con Ploeh. Si eliminamos el prefijo del espacio de nombres, también tiene sentido cambiar el nombre de los ensamblados (por ejemplo, de Phoeh.AutoFixture.dll a AutoFixture.dll ). Creo que NuGet manejará este cambio con elegancia. Lo único que nos podría preocupar es que esta será una nueva identidad de ensamblado y será imposible realizar la redirección de ensamblado de la v3 a la v4.

¿Qué opinas de esto @moodmosaic , @adamchester y @ecampidoglio ? ¿Tienes objeciones con respecto al cambio de nombre de la asamblea? Parece un cambio importante, pero no está listo para evaluar cuánto.

Una vez que se cambie el nombre de los espacios de nombres en la versión 4, la redirección del enlace del ensamblado a la versión 4 no tendrá sentido. Por esta razón, y para ser coherente, creo que tiene sentido cambiar el nombre de los ensamblados a AutoFixture (. *).

Buen punto, me perdí eso. De hecho, todos los tipos de nombres completos serán diferentes, por lo que la redirección no tiene sentido. A menos que @adamchester y @ecampidoglio tengan otras preocupaciones, cambiemos también los nombres.

¡Hecho! El espacio de nombres "Ploeh" y el prefijo del nombre del ensamblado se eliminarán de la versión 4, de modo que comenzará con "AutoFixture" en su lugar. Este cambio permite reflejar la propiedad actualizada, ya que ahora el producto está siendo desarrollado solo por el equipo de AutoFixture.

Tenga en cuenta que esto rompe la línea de continuidad en lo que al montaje se refiere. Es decir, el nuevo paquete no contendrá una nueva versión del ensamblaje. Por el contrario, el ensamblaje anterior se eliminará y se reemplazará por un ensamblaje completamente nuevo, con una nueva identidad. Esto significa que cosas como redirecciones de enlace no se pueden hacer funcionar entre el ensamblado contenido en el paquete 3.xy el ensamblado contenido en 4.x.

Quizás esto no sea un problema, pero pensé que vale la pena señalarlo.

Por cierto, ¿ha comprobado el comportamiento de NuGet cuando se actualiza el paquete? Para proyectos de estilo SDK, supongo que todo funcionará bien, ya que el proyecto solo contiene un elemento <PackageReference> que apunta al paquete en lugar de ensamblajes. Pero con csproj de estilo antiguo, puede valer la pena verificar que NuGet realice el cambio deseado en la referencia de ensamblado, de un ensamblado a otro.

@adamralph ¡ Gracias por sus preocupaciones!

Esto significa que cosas como redirecciones de enlace no se pueden hacer funcionar entre el ensamblado contenido en el paquete 3.xy el ensamblado contenido en 4.x.

Sí, lo sé. Sin embargo, ya hemos cambiado el espacio de nombres predeterminado, lo que significa que cambiamos la identidad para todos los tipos dentro de los ensamblados. En este sentido, la redirección de enlaces de ensamblados no tendrá sentido ya que el código no funcionará en ningún caso sin la recompilación y la corrección de importaciones. Por lo tanto, creo que estamos totalmente de acuerdo con eso. Es un gran cambio, pero sucederá solo una vez.

Por cierto, ¿ha comprobado el comportamiento de NuGet cuando se actualiza el paquete?

Sí, ya lo he probado y funciona bien. Lo único que debe hacer es ejecutar el reemplazo de texto para arreglar using Ploeh.AutoFixture en using AutoFixture . Después de que el proyecto se compile con éxito y las pruebas se ejecuten con éxito.

Lo único que debe hacer es ejecutar el reemplazo de texto para corregir el uso de Ploeh.AutoFixture para usar AutoFixture. Después de que el proyecto se compiló con éxito y la prueba se ejecutó correctamente.

Sí exactamente.

¿Fue útil esta página
0 / 5 - 0 calificaciones